Strange public IPv4 address assigned behind NAT (2019) | Hacker News Reader

Strange public IPv4 address assigned behind NAT (2019)

broadbandforum.co

85 pointsrohan102488 comments

Microsoft use 25.0.0.0/8 for some of their cloud services: you can see it in mail headers from Hotmail and Exchange Online. (Or could - I have not looked recently to see if this is still the case.) Microsoft stated on the mailop list on 16 July 2016 that they have an agreement with the MOD that it is OK to use these addresses like this. I don’t know if other organisations squatting on this address range have similar agreements...

NAT breaks certain things, and broken NAT breaks them further. The specific thing I can speak of is VoIP or more accurately SIP. SIP was designed for the public internet and so there are NAT workarounds, such as: if my interface has an RFC 1918 IP, I’ll use STUN along with certain SIP headers and tags to indicate I’m behind a NAT and need special treatment by the remote SIP agent. Using public IP space as NAT foils this logic entirely.

Apparently hamachi also uses the 25.x.x.x ip range for their vpn interfaces[1]. Not sure why anyone would use a random delegated range when there are plenty available, especially the 100.64.0.0/10 range.

[1] https://support.logmeininc.com/central/help/about-the-hamach...

TIL: https://networkengineering.stackexchange.com/questions/35958...

I am not surprised. Private networks conflicting with each other has burned me before. So they are probably using a range that technically breaks the Internet, but in practice, doesn't break their customers' internal networks. Horrifying on some level, but no doubt necessary to sell an enterprise product.

I had some troubles with AWS when I created a VPC private subnet that happened to conflict with an internal IP range used by Docker. (You can change that, but not if you use their managed k8s offering. At the time it made sense, but, upon further reflection, I am baffled as to why Docker needs IP ranges outside of what the k8s CNI gives it. But I can assure you -- stuff broke in exciting and fun ways!) It was at that point I realized we had to have some central management of "internal" IP addresses, just like the IANA but for internal addresses. We were an ISP, so we already used Netbox, and it ended up being quite straightforward. Plus, the documentation was great -- you would see a connection from 10.42.123.8, look it up in Netbox, and see "oh that's the management network in NYC-FOOBAR-42".

Anyway, be careful about private subnets. Someone else already has a private subnet with that IP range, and those two networks can never talk to each other. No doubt, some Hamachi customer ran into this problem at some point in the past ;)

It is possible to have those networks talk to each other using bi-directional 1:1 NAT, but it will almost certainly cause you far more trouble than it is worth. I have done it, and I don't recommend it.

100.64.whatever was defined in 2012, which is like yesterday in internet terms. Hamachi is much older than that.

I saw this years ago on Rogers mobile devices in Canada. Freaked me out when I noticed it. But then it's behind NAT, so whatever. Always wondered why they chose that address space though. Like there aren't enough addresses to use in 10/8 or 172.16/12

> Like there aren't enough addresses to use in 10/8 or 172.16/12

10/8 only has 16.7 million IPs. According to Google, Rogers has 10.8 million subscribers. Considering private IP blocks usually can't be 100% utilized (because of subnetting), it wouldn't surprise me if they've exhausted the actual private IP ranges.

Forgive me, I'm far from wearing a network hat and still struggle to wrap my head around things after 15 years. I don't know if this will make sense.

But seeing as the ISP uses NAT anyway, is there any way to further route the private ranges behind private ranges? I don't know if this is what 'Double NAT' is, I tried searching online to see if this would work or if it would cause all sorts of issues. I'm not too familiar with ISP Natting as my home ISP has always assigned a public IP address.

Kludges like that are possible but it puts you into an even deeper circle of hell. The solution is probably something like 464XLAT.

I'm no ISP network engineer, but at a guess I'd probably look at splitting up customers into some sort of logical grouping (say per state or something) where they all sit behind the same CGNAT infra anyway, and give each of those their own 10/8.

Definitely. I've seen tethering implementations that put the tethered device on its own NAT, behind that of whatever network the host device is connected to.

Yes, you can keep NATting the same address space as many times as you want. As long as you have proper network boundaries there's nothing preventing, say, your ISP from using 10/8 for the country, then each province having a router that NATs 10/8 up to your gateway, which then NATs 10/8 for your home network.

But the further you go into the NAT layers the worse performance you'll see, because each NAT adds some latency overhead and more places where things can go wrong.

There's no reason an ISP can't overcommit a /8 network. There's no particular reason they need to promise that you can reach the IP of another Rogers subscriber. One "instance" of 10/8 per region or household or whatever would work just fine.

It would maybe work, but it would also vastly complicate everything. Debugging and logging, setup, maintenance would all be rigged to support that address reuse.

If you have dynamic allocation of customer IPs, you have to store that data anyway.

Yes, but you need a lot more gateways, jumphosts and general indirection to deal with the different network segments. And you need to customize a lot if stuff, because you can't just log "it came from 10.12.13.14", you need to log the network segment and gateway it came from as well. Non-flat address spaces are hell.

That said, the real solution is IPv6

> but you need a lot more gateways, jumphosts and general indirection to deal with the different network segments

That hardware is already there. You don't think they share one giant switch between 16M addresses, do you?

That hardware isn't already there. They won't share a switch, but they will share routers. IP routing with overlapping networks doesn't really work, so you have to get creative with e.g. DNAT or proxies. Both of which consumes additional resources, even if the routers can do it, you will have to buy bigger licenses, processors will have more load, etc.

FWIW, you can easily use all but two of the addresses in a /8 if you set your subnet mask to 255.0.0.0. MIT used to run their public IPs this way. The entire campus was one huge switched network. You could get any IP in their /8 and take it anywhere on campus.

Thinking about the amount of ARP alone in that subnet (let alone other types of broadcast traffic) is horrifying...

At least it would be bounded by the number of students and staff, ie around 10k / 2^14.

"smart" switches which don't allow broadcast and direct ARP packets only to the correct destinations can fix this.

Many colleges ran this way in the 90's. I am familiar with several that had flat /16's, no subnetting.

Yes, in a simple routing setup, the limiting factor is how many ways you can divide up your address space hierarchically, not some giant 2^N number.

10../8 could be split into three hierarchies each with 2^8 entries:

• 10.X../16: sites (e.g. global offices)

• 10.X.Y../24: on site vlans / individual buildings, typically a broadcast network (although switches use MACs to limit actual broadcasting.)

• 10.X.Y.Z/32: individual hosts

It’s not an enormous amount of space, really, hence IPAM. You could divide it on non-8-bit boundaries. Oof.

With 128-bit IPv6, each ISP has a /32, each client a /48, and each broadcast domain a /64, leaving a remaining 64 bits for clients to just randomly make up addresses as they wish.

That’s still 16-bits of address space to work with when creating networks (just as you have 16-bits for the X.Y in 10.X.Y../24) but all addresses are globally routable and each network can support essentially infinite hosts and without needing DHCP, instead of just 254.

> each broadcast domain a /64, leaving a remaining 64 bits for clients to just randomly make up addresses as they wish.

What's the use of this especially when the prefix is dynamic? Two major cellular ISPs in India hand out dynamic prefix IPs. Are they doing it wrong? Are ISPs supposed to hand out static mac bound IPs for ipv6?

> It’s not an enormous amount of space, really, hence IPAM. You could divide it on non-8-bit boundaries. Oof.

Why not? I do this all the time.

Would you use a single NAT for a whole country? I always assumed ISP network infrastructures were regional. Not the least because if you put 10 millions IPs behind a single public IP, you will quickly run out of your 65000 ports.

I can't recall, does TCP require that src:srcport->dest:destport pairs be unique, or is there another way to distinguish connections (sequence numberd maybe?)? I guess there are other IP protocols like UDP though...

I'm not an expert in this field, but I did come across the carrier-grade NAT range on a very odd project:

https://en.wikipedia.org/wiki/Carrier-grade_NAT

You can use more connections than 65k, since connections are identified by srchost, srcport, desthost, and destport. You are restricted to 65k NATted connections to a single server's* web site, though.

*Assuming the server is using a single IP.

Good point, but still, there aren’t that many google, instagram or windows update IPs. I can easily imagine more than 1% of the 10 millions people connecting to google simultaneously.

> Always wondered why they chose that address space though.

So that their customers are free to use any RFC1918 space they want for their own networks, either on the customer network behind NAT or on VPNs the customer's connected to.

Works fine until you want to connect to the network that owns that IP address in the real world. Unlikely but possible.

No networks in the real world have a 10.0/8 or 172.12/12 range (that you from another network can route to), that's the whole point.

That’s why you’re supposed to use these addresses unlike the people in the story who are using addresses that belong to someone else.

What you are actually supposed to use is real unambiguous ip addresses.

This shouldn't be downvoted, it is the correct implementation.

The UK MOD needed a large, private network space, so they registered 25/8. They can make whatever integrations with other networks they might need, and know their private address space shouldn't collide.

And today anyone can do it with ipv6.

Companies buy each other. They often have overlapping IP ranges which causes all sorts of headaches all the time.

Users who VPN into their business partners or clients frequently run into overlapping networks too.

I used to work for a service provider, that solved the MPLS administration problem by hijacking 7.0.0.0 DoD space that wasn't publicly routed.

By using 7.x IP assigned loopback interfaces in customer MPLS space, we could export just the loopback interfaces into our managment vrfs (without burning our supply of public IPs.) Of course the one problem is that we'd never have been able to take a Federal contract...

Did you consider using ipv6 for this?

I did a project with a bank where we had to connect our stuff to theirs via a VPN, but they required that the addresses inside the VPN were notionally public - so no 10.x. We borrowed 51.x, which at the time was used by the UK's Department of Work and Pensions but not actually routable. Occasionally new people on the team would ask why the VPN was called VPN-DWP-1.

The thing that would worry me is if they one day sell that address space to someone else.

I rebuilt a corporate network for a relatively well known CGI company around a decade ago. They had chosen to use a subnet owned by a big tech company as their internal network. Took me months to convince the CEO that a change was necessary. Ultimately they were unable to download something important that caused them to suddenly care.

Let me guess. 17.?

Back when I worked in IT (15+ years ago), I went onsite to a bank that used some seemingly-random /20 subnet for their internal network.

Turns out that they had some piece of hardware that came with a "hard-coded" IP address (from Japan) and instead of figuring out how to change it, they just used that entire subnet as their internal range.

It took me several hours to figure this out as I was working on their Cisco equipment and trying to add sane firewall rules...

I used to work on IT too (10+) and I was sysadmin in a bank (same?) and I was really puzzled when I saw SSH connections to the Sun servers from japan. I took me some time to realised that It was from our own systems.

I had a client that was using a random, allocated class A, and had been since the 80s. When I said "you know...these addresses belong to someone else", their IT director shrugged and said "no one here needs to talk to Japan". No...I never did find out why they thought 133/8 was a cool network to hijack, but I did make a ton of consulting money readdressing them when they found out that using someone else's IP addresses had bigger implications than they thought.

This kind of thing seems innocent, but it really isn't.

Another comment put it as "25.x.x.x is not advertised globally, not announced with BGP, so they're using it as private IP space. This works because you will never connect to a 25.x.x.x IP. It's just NAT."

That sounds fine but you run into trouble when the owner suddenly starts using the space or it’s reallocated. This has happened quite a lot in the last decade as IP space was ever more in demand and thus ever more scarce. An example is the use of 1.0.0.0/8 - allocated to APNIC in 2010 - there is a detailed analysis of the "unintentional" traffic this network was receiving when first used https://www.potaroo.net/studies/1slash8/1slash8.html - over 165 megabits in 2010.

Among various lazy configs and people using the range as it was convenient I recall there was some default popular Cisco recommended config that used it. Though I can’t find a link right now.

Similar problems also happened in the 2007-2010 timeframe as a lot of people used to have static “Bogon filter” firewalls that dropped traffic from unallocated IP ranges (not those marked as 'never to be used', just those not allocated yet). As more and more ranges were allocated the people receiving them had all sorts of connectivity problems to random networks because of these old out of date static filters - in my experience as a hosting provider the most common offender was banks hilariously. In practice these filters provided relatively little security and just broke things instead some years after they were put in place. If you had a dedicated team managing your network and constantly watching these kinds of things - hyper-aware the filter was in place and vigilant to update them then maybe it’s a tactic you could use but as static network config that is left and forgotten about it was a terrible idea and I spent a lot of time chasing down working contacts for various networks to get them to fix their firewalls. Meanwhile as far as our customers (trying to use the IP space) are concerned it was our problem since it worked fine should they use another provider. And this was just a network in the 110.0.0.0/8 range - no fancy 1.0.0.0.

Back to this specific case. If for example we wanted to extend IPv4 a little more and the UK DOD decided to sell or allow this range to be reallocated (since as rightfully pointed out, it's not really being used right now) there would be a lot of problems using it because of configurations like this. And you have a bit of a chicken and egg problem in that you can’t really use it until it mostly works but people won’t fix their networks unless people are using it.

Hence why sounds kind of innocent but in practice these are terrible ideas and using IP ranges for purposes they are not intended for shouldn't be done.

This is partly why for CGNAT applications like this a new range was reserved in 2012 - 100.64.0.0/10 which is what should be used here. The reason to have a dedicated range for the “ISP side” rather than just using RFC1918 space is so it doesn't clash with whatever RFC1918 space the end user wants on the LAN side of their network. If both sides used RFC1918 and accidentally chose an overlapping range then the connection would not work.

The internal use of global but not actually BGP advertised ranges is very common for many reasons.

This needs a (2019) added, or maybe a link directly to the newer posts.

Its still true though my public IP is 157.x.x.x while behind NAT it's 25.x.x.x

25.x is assigned to UK defence ministry as per the thread. Any ideas?

25.x.x.x is not advertised globally, not announced with BGP, so they're using it as private IP space. This works because you will never connect to a 25.x.x.x IP. It's just NAT.

> you will never connect to a 25.x.x.x IP

Unless the UK decides to sell it. An IPv4 /8 is worth at least $250 million at the moment.

$250 million is pocket change to a nation state.

I own a /24 myself (it's routed), and would never sell it.

When you say owned, do you mean like a PI or legacy allocation?

Yes, it's a legacy allocation from the early 90's. It predates ARIN.

There aren't enough private IPv4 addresses for large(ish) mobile networks to address all their customers devices. Some networks work around this by using public v4 addresses which simply aren't in use. The UK DOD's block has never been publicly advertised (AFAIK) so they decided it was a "safe" block to use for this purpose. This isn't a new practice - I remember seeing Sprint doing this same thing many years ago.

The "correct" way to handle this would be to reuse real private IPv4 addresses within your network by segmenting it somehow, or do what some networks have done (T-Mobile US is probably the biggest) - use IPv6 with NAT64. That lets them forego internal IPv4 entirely and only use it at the edge for NAT.

So if UK DOD chooses to publicly advertise someday my Internet will break.

Good to know.

No, you just would not be able to reach UK DOD.

On reconnection got a 56.x ip so USPS as well.

Or whoever they transfer their address space to, if they try to be more socially responsible, which might end up being the next cool startup.

That would be socially irresponsible. Use IPv6.

I suspect major cloud providers may well end up buying the address space if it were to become available, so quite a few companies' services may not be reachable.

That's the best case scenario, considering that most customers probably don't need to connect to UK DOD. With the way IPv4 shortages are going, the more likely scenario is that some cloud provider/cdn buys that range, and sites start breaking randomly for customers.

Perhaps. They sold a block to Microsoft to host O365 and Azure AD components a few years ago!

Is there a list or some way to discover which blocks are like this that aren't in use?

https://bgp.potaroo.net/ipv4-stats/prefixes_unadv_pool.txt

Is this complete? All of 4.0/8 10.0/8 12.0/8 15.0/8 16.0/8 17.0/8... are unrouted?

Edit(v2): Complete list of unrouted (per that list) /8s along with their IANA designation

0: IANA - Local Identification

4, 15, 16, 32, 40, 44: Administered by ARIN

10: IANA - Private Use

12: AT&T Bell Laboratories

17: Apple Computer Inc.

38: PSINet, Inc

53: Daimler AG

55: DoD Network Information Center

57: Administered by RIPE NCC

73: ARIN

126: APNIC

127: IANA - Loopback

214: US-DOD

224 to 239: Multicast

240 to 255: Future use

(designations from https://www.iana.org/assignments/ipv4-address-space/ipv4-add...)

> All of (...) 17.0/8... are unrouted?

Definitely not complete:

    apple.com.              1424    IN      A       17.172.224.47
    apple.com.              1424    IN      A       17.178.96.59
    apple.com.              1424    IN      A       17.142.160.59

Most of these are routed and in very active use. I have suballocations of large chunks from 12/8 and 38/8. People will be unhappy if you picked most of them.

73/8 is entirely owned by Comcast and used for customers. 44 is no longer a /8, but sold+split and half in active use by AWS.

25.* is not larger than 10.*. What problem does this solve?

They probably were already using 10 for something else when they decided to use 25.

Maybe not having to field tech support calls if their choice of private IP space conflicts with a customers choice?

I've seen 26.x.x.x get used as well for the same reasons. (US Department of Defense)

Why?

Apparently this is a common practice at IBM, I had a friend tell me even the printers are assigned a public IPv4 addr even behind the NAT

I use Mint Mobile (a T-Mobile MVNO) and I also get an IP Address that officially belongs to the UK Ministry of Defense. I have always found it weird.

Question (if it's seen): How can I see The List of all non-BGP-announced address ranges?

C'mon. Everyone knows that Class E space is the new 8/8.

If it’s behind NAT, anything can be used but best practice is to just the 10s

Does that actually work? If ISPs assign, say, 8.8.8.0/24, then you're going to have trouble determining whether that DNS lookup bound for 8.8.8.8 is 8.8.8.8 on the Internet or 8.8.8.8 on some link-local host.

Because people typically use IPs designated as private behind a NAT, this isn't a problem in practice. But if you start using publicly-routable IP addresses internally, then you can create some fun problems. Actually, not even that fun. Just annoying.

NAT usually translates a private ip to global ip, in your case there should be an internal DNS to resolve internal names

You're missing the point; 8.8.8.8 was just an example. For any public IP assigned inside your network, clients trying to reach to the real address won't be able to get there, because they'll hit the internal one instead.

Best practice for an ISP that is implementing CGNAT is to use 100.64.0.0/10 as per RFC 6598. That way, your customers can use private IPv4 (10/8, 172.16/12, 192.168/16) and you can manage your ISP network in the 100.64.0.0/10 space.

Your CGNAT looks after translating your customer's ISP address (ie, the 100.64.0.0/10 side of their CPE).

Of course, the best solution is to move to IPv6 and allocate each customer: * a /64 address out of the ISP's network space * a /48 (or /56) delegation for their own network

See https://www.ripe.net/publications/docs/ripe-690

Reply on news.ycombinator.com