22

Is it possible to use global IP addresses without internet?

Obviously, private IP addresses should be used without internet access. But I'm curious whether we can use any IP address as private IP. Is it possible to do so?

For example, can we use 8.8.8.8 as a private IP address in a private network (which does never have access to internet, so no one in the network knows 8.8.8.8 is being used as Google DNS)?

  • 54
    Yes, but why would you want to? – DavidPostill Mar 22 at 8:22
  • 11
    @DavidPostill This 8.8.8.8 setting can be useful if someone wants an offline local network, which is compatible with occasionally attached devices having a hardcoded 8.8.8.8 dns. For example, you have embedded systems with hardcoded dns set to 8.8.8.8, used mostly on the internet. If you attach them to your local, offline network, they will still be able to use dns (but they will see your local DNS and not the google). – peterh - Reinstate Monica Mar 22 at 19:59
  • 20
    @peterh a more competent way of doing this would be to intercept traffic on port 53 and redirect it to your nameserver. The problem is where do you draw the line. 8.8.4.4 and 1.1.1.1 are commonly used as well, and I am sure there are others. Also, why would you hard code DNS when you use DHCP - and if you are not using DHCP, chances are very high your network wlll be broken anyway. Bottom line - don't use 8.8.8.8 in your network unless you are Google. – davidgo Mar 22 at 20:43
  • 1
    @davidgo Not all embedded devices like dhcp. It is a complex protocol. A friend of mine has now a hard project, developing firmware in C++ for 24kB flash. I don't use 8.8.8.8 in my networks, I don't believe in the "security" of offline networks, but I have no way know the preferences of the OP (and the external limitations and "surprise wishes" of his company/bosses/customers). Sometimes we need to do dirty things so adequatebly as possible. – peterh - Reinstate Monica Mar 22 at 21:00
  • @peterh-ReinstateMonica wont work with DNSSEC, no? For example, I'm pretty sure Chromecasts use either DNSSEC or DNS-over-HTTPS and they will not fall for tricks with a fake server or redirecting packets by port. – Bakuriu Mar 23 at 8:00
66

It is absolutely possible - there is nothing magical about IPV4 space, and it all works the same way. The headaches come many years down the line when this network gets integrated into the Internet.

| improve this answer | |
  • 14
    Or when you need to interface with another private network that is internally doing the same. That even goes for 2 private range networks if they happen to use overlapping ranges. I had to setup a router between 2 companies using 10.0.0.0/8 internally. Got very messy with having to use NAT in both directions. – Tonny Mar 22 at 9:45
  • 17
    Don't forget when Hamachi used the "unused" 5.0.0.0/8 for its VPN service, and then ISPs began using it for real... Or when Cloudflare received 1.1.1.1 and it was discovered how many networks had "borrowed" it for internal usage. – user1686 Mar 22 at 11:10
  • 40
    1.1.1.1 was known to be a widely-abused IP long before cloudflare got it. Indeed as I understand it that was part of the reason that APNIC were prepared to give it to cloudflare, noone without a massive global network able to absortb a ton of crap could reasonablly use it on the internet. – plugwash Mar 22 at 17:28
18

Yes its possible, but not recommended.

Instead you should use the RFC1918-allocated blocks, and a small a network as you can. Avoid using 10.0.0.0/8 for your home network with a handful of devices.

More details at https://tools.ietf.org/html/rfc1918 and its replacement https://tools.ietf.org/html/rfc6761

A good rule-of-thumb is to use a network size of 4x the maximum number of devices you could run on that network, or a /24 (254 hosts) whichever is larger. A /24 also simplies subnetting.

So use 10.yourstreetnumber.yourbirthyear.0 or 192.168.yourheightincm.0 Be creative!

If you're likely to create a site-to-site VPN, consider the 172.16-through-31.0.0 range as a candidate - because its a bit messier and is therefore less used.

Another reason for not using an existing public range, is that dns caching could mess up devices that change networks. IE laptops and phones and tablets could cache "dns.google.com" as 8.8.8.8 and keep using that record once they connect to your LAN. Or someone goes home and your hostname of "fileserver.local" resolving to 8.8.8.8 could be cached for up to the TTL of the record.


Example of stupid IP reuse - Back in the days of vmware workstation I tried using 127.99.99.0/24 as an IP network, on the basis it was more-specific than the 127.0.0.0/8 applied to loopback interfaces.

This worked perfectly for vmware, and for linux VMs. But windows (xp?) said "Stop, no" as soon as you put 127 in for the first octet of the IP address. I never tried allocating IPs via DHCP at the time.

The possibilities of unintended consequences are enormous.


And sometimes, rarely, classful networking messes you up. I used to run a network which was 192.168.0.0/16 and it had many things coexisting happily, windows 95, XP, NT4, linux, macs, printers, etc.

Then we got a bunch of Linksys WRT54GL APs, and they would not accept a netmask larger than /24 when used with 192.168. This is because originally 192.168.0.0 was defined as

256 contiguous class C networks

So network had to be 256 hosts or smaller. This only ever appeared with some linksys kit, and a flash with OpenWRT was happy to use the full /16 network.

Upshot of this is a /24 is more than enough for most users. A /8 or /16 is silly-oversized.

| improve this answer | |
  • 5
    Well, the whole 127./8 was officially reserved for "loopback" use, so Windows is hardcoded to honor that, and even Linux will need some sysctl tweaking. Same goes for 240./4 (aka "class E"), which Windows will refuse as it was never allocated for unicast use (but Linux will route it fine). And this is probably one of the reasons why the IPv6 spec explicitly states that "all address space is unicast unless specified otherwise"... – user1686 Mar 23 at 10:07
  • Does 6761 "replace" 1918? The links you have show only that it "updates" the latter, and it doesn't seem to explicitly say anything about the IP address allocations at all. – ilkkachu Mar 23 at 11:15
  • 3
    Interesting examples, but lots of street numbers are >255... even in my smallish city my own street number is almost 3x that, and there's a street in Topaz, CA that exceeds 120000 – Doktor J Mar 23 at 21:55
  • 1
    @DoktorJ yeah fair enough - and very few users will have heights in cm from 0cm to ~150ish. The point there was to not go for the 192.168.*0*.0/24 or 1 or other common numbers, to try and mix it up a bit. Can't think of a good common thing that has a range of about 1-255 with a random distribution. Perhaps "your street number modulo 255" ? – Criggie Mar 23 at 22:12
  • 3
    I like that, though it's a bit more cantankerous to write "192.168.$((yourstreetnumber % 255)).0" and more difficult to understand, especially for those with lesser backgrounds in networking/programming. – Doktor J Mar 23 at 22:15
8

Yes, this can be done. No, you don't want to. Unlike some other answers I see, I'm about to delve into more details of why (particularly for my second sentence).

Let's say you control a computer, and you can set it's IP address. And so you type in an IP address of 8.8.8.8. Can you do that? Yes.

Now, "routing" could be an issue (as I'm going to elaborate on in a later part of this answer). However, there may be ways around that. So, let's say that a remote end contacted your ICMP server and ran "ping 8.8.8.8". Would your ICMP server (typically built into "TCP/IP stack" software components) respond? Yup. No problem.

Let's say that you start up a server on this computer, such as a DNS server. If your computer was running a DNS server and received the response, could it respond and could everything work? Yes. No problem.

Let's say that you start up an HTTP server. If another computer opened up a web browser and ended up communicating to your computer with the IP address, then could your computer respond and everything work? Um... well... it used to be that the answer was "Yes". But, now, things got a bit more complicated due to HPKP. For more details, you can see Wikipedia's web page on HTTP Public Key Pinning]. So, that might not work so well. To summarize: popular web browsers considered this a style of attack, and came with some details about proper HTTPS certificates/connections for some of the world's top sites. Another related technique may be "HSTS preloading", which is related to HSTS ("HTTP Strict Transport Security"). So, when people install modern versions of web browsers, those browsers may come with some details about some websites. If your fake "Google" site doesn't match expectations, the browser may intervene (and presumably let the end user know of a problem).

And, as you suggested, if you do these sorts of things, the legitimate site won't be able to be contacted on this IP address.

Now, why am I saying you don't want to do this?

First, there is a better solution. Have devices rely on DHCP. Then, on your local network, have a DHCP server that points places to use your local DNS servers, at a sensible address (e.g., FEC0:0:0:ffff::/126 or an IPv6 address starting with fd or perhaps fec0:, or IPv4 using the address ranges from IETF BCP 5 ("RFC 1918")). If you standardize that for client machines, then mobile systems will likely work remotely and on your local network as desired.

The big challenge with doing things as you expect is routing. If you set up an address at 192.168.55.3/24 and another computer at 192.168.55.105/24 tries to communicate with you, then the computers will recognize the /24 (a.k.a. a subnet mask of 255.255.255.0) and figure out that anything matching the first three octets (starting with "192.168.55.") is on the local network, and will try a direct communication.

If a DNS client is at 192.168.55.105/24 and try to communicate with 8.8.8.8, then the computer will recognize that 8.8.8.8 does not match the first three octets, and so the computer will attempt send the traffic to a gateway device, most commonly a "default gateway" which sends information to the Internet. (This "gateway" device needs to be on the local network. Using more technical terms, the gateway needs to be in the same subnet.)

So, there are three approaches that could be done to still get your computers to communicate with 8.8.8.8

  • You could make your client systems illegitimately use the 8.8.8.0/24 range. Then 8.8.8.8 would seem close. Note that this would break valid communications to 8.8.8.8, and you couldn't simultaneously use this strategy to also have your local computers be in the same close IP range as a different address.
  • You could make your local system use 192.168.55.105/0 instead of 192.168.55.105/24. This means you're using a subnet mask of 0.0.0.0, so now you've effectively convinced your computer that 8.8.8.8 is a local address. So communications won't go to your "default gateway", but instead communications will try to reach 8.8.8.8 directly on your local network. If both the client and server are doing this, that will likely work.
    • However, using the extreme example shown here, what you've effectively done is convince your computer that all IP addresses are part of your local network. So, this illegitimate method has now convinced the affected computer that the entire Internet is to be treated like it is on your local network. Now instead of breaking communications with the legitimate Google site at 8.8.8.8, you've effectively broken communications with all legitimate IP addresses on the Internet. Ouch. Bad.
  • You could set up some custom routing on your "default gateway" device, so that information sent to 8.8.8.8 gets redirected to the local IP address of your desires, instead of getting passed onto your Internet service provider.

While the third approach could theoretically work without too many problems or unwanted side effects, the biggest drawback is that it requires that you muck around with traffic routing. If you're going to muck with something, I suggest that you understand it well first.

As someone who does understand traffic routing, I would suggest that you may need some amount of expertise to successfully break the legitimate connections that you want (to the real 8.8.8.8) while not also breaking legitimate connections that you don't want broken. And if you have that much expertise to pull that off, then you probably also have some expertise to simply run a DNS server on an established private address. So, why not do things in the standardized way which is less likely to cause weird rare side effects that are harder to foresee and troubleshoot?

In answer to what you asked and how you asked it, yes, technically something like this could be possible. But do also keep in mind that if communication isn't going to where it should go, then that is often described as a "Man In The Middle" ("MITM") attack. Web browser connections have already evolved to support HKPK to defeat such shenanigans. A lesser-known fact is that DNS has largely been replaced with using EDNS (using "Extension mechanisms for DNS"), and a more widely known fact is that there are some newer enhancements to DNS security called DNSSec. If you were unaware of any of this, then realize that the current maintainers of popular Internet-based software code might already be way ahead of you, so you might want to keep that in mind before trying to include an "MITM-attack" as a critical part of some sort of fancy new design of any network you oversee.

So, to summarize, the main reason I think you don't want to do this for a real network (rather than a test lab where you're exploring possibilities) is simply that, to accomplish useful legitimate goals, there is a better way. Which is, when you're trying to design how your network behaves, do things the right way. You're likely to experience less pain overall.

To re-clarify in case this was forgotten, the "right way" I am referring to is to just operate your local DNS server on a private address, fooling nobody, and encourage computers to use the local private address or to rely on DHCP, and have your local DHCP servers tell devices to rely on your local DNS server. It is a more honest style of design which doesn't break the ability to communicate with a public site, and is widely supported so maintainers of Internet standards are less likely to do something that breaks such a legitimate design on many local networks used throughout the world.

| improve this answer | |
3

Not only it can be done, but I have seen a few networks made by illiterate admins featuring global IP addresses AND connected to the Internet (via NAT firewall).

The only real problem is being unable to access the legitimate network having the same IP range. Not a big deal for some 256 IP addresses somewhere on the big, big Internet.

| improve this answer | |
  • This answer contributes nothing beyond the current answers. Consider providing more detail. – phbits Mar 23 at 18:44
  • 100.64.0.0/100 (ie 100.64to127.255.255) or 169.254.0/016 are useable, or there are three "test networks" like 203.0.113.0/24 which can be used, according to RFC1918. – Criggie Mar 23 at 18:57
3

In theory, that should be fine.

In practice:

  1. May break third-party assumptions.
    You might use software/hardware that assumes certain well-known IP conventions will hold, causing unintended behaviors when you break these assumptions.

  2. May trigger hidden bugs.
    Some buggy software works fine in most cases, but weird specifics might trigger them. Such bugs can get fixed when noticed, but if you use a non-standard configuration, the potential to encounter bugs no one else has had a chance to run into before may increase.

  3. May confuse others working with your network.
    Even if you're cool with remembering that 8.8.8.8 means something else in your internal network, this could potentially confuse others. Coworkers, tech support, folks reading a log you might share on a help-forum, etc., might have trouble with it.

  4. May create contradictions in caches.
    If any devices on your network were previously connected to the global internet, they may have IPv4 addresses stored in their settings, firewall rules, etc., potentially causing undesired collisions when they join the local network.

In theory, poor third-party designs and bugs might not be your fault. But in practice, you might start to believe in ghosts.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.