0

I am a software engineer at a cloud software company. As is typical, we have an internal "dev" environment to which we deploy the latest unreleased versions of all of our microservices to AWS.

The web URL a user would use to access our dev environment something like app.dev.company-dev.com. company-dev.com is resolvable only within our corporate VPN.

In the process of doing a bit of network routing to allow traffic to reach this host from another AWS VPC, I looked up app.dev.company-dev.com's IP address. I was connected to the VPN at the time. nslookup reports that the IP is 240.x.y.z, where there are a handful of different values for x.y.z returned with successive requests. Just a bit of load balancing I'm sure; no concerns there.

Anyway, I didn't recognize 240.* as being part of one of the subnets we manage, so I went to one of those websites where you can look up information about an IP. My working theory was that we had that name protected by CloudFlare, and that the IP was one of theirs. So I pasted in the IP, and the website came back with an error saying it was an invalid IP. What? Tried my own public IP and it worked fine.

So I went to another IP testing site, and it came back with a much more helpful but equally surprising (to me) message:

Addresses starting with 240 or a higher number have not been allocated and should not be used, apart from 255.255.255.255, which is used for "limited broadcast" on a local network.

At this point I learned about the "reserved for experimentation" nature of Class E addresses. On a hunch that the IPv4 address space squeeze had led to some changes at some point which were just not reflected in the tools I had tried so far, I continued to try several more IP info sites, but no. Best I can tell, Class E is still reserved, and most routers simply drop any packets with that as a destination, which explains why attempts to ping or traceroute that IP simply time out.

But, all that said: if I load that IP in my browser (while connected to the VPN), I get a broken-but-clearly-ours version of our webapp (I wouldn't expect it to work entirely correctly by IP). If I load the hostname? Works perfectly, as it always has.

What's going on here? How is this possible?

Improve this question
2
  • 2
    They aren't public IPs, so won't show up as owned by anyone. There's nothing stopping you from using 240.0.0.0/4 IP addresses internally - companies like Verizon and AWS have used them in the past for example. Somewhere along the line of you > company vpn > company network > AWS connection > app, the edge for that app is using the IPs you're seeing.
    – Cpt.Whale
    Commented Feb 5 at 17:19
  • 2
    There is no such thing as a "Class E address". Classes have been abolished thirty years ago.
    – Tilman Schmidt
    Commented Feb 5 at 17:54

1 Answer 1

Reset to default
2

most routers simply drop any packets with that as a destination, which explains why attempts to ping or traceroute that IP simply time out.

Some routers do that1, but some treat it as a regular unicast IP address range and will route it as long as they have routes for it.

Linux, in particular, has no hardcoded restrictions about using these addresses, e.g. for an internal network. It could be that you cannot ping the address simply because it's assigned to a host that doesn't answer pings; or that it's used as part of some NAT scheme (I suspect NAT46).

1 (IPv6 learnt the lesson and explicitly stated that not-yet-allocated address ranges must be treated as general unicast ranges rather than being walled-off, to prevent another "Class E" from happening.)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .