ICMP - Source/Destination Subnet Addresses

[petenixon]

Hi guys,

I have noticed something very weird on our firewall this morning, i'm seeing ICMP traffic being dropped with the following source/destination addresses:

Source: 10.150.0.0/16
Destination: 10.201.84.0/16

The traffic is originating from a VPN tunnel from an Azure cloud network, my question is how is this possible? It is my understanding that the network address cannot be used?

Thanks.

[eduardopozo56]

10.X.X.X range is inside the "private ip adressing" range (RFC1918). This networks are not routable on the internet
But as you said, the traffic is originating from a VPN tunnel. A VPN tunnel can be made between two public peers (with public addressing) but the traffic flowing inside the tunnel can use private addresses.
Actually, this is one of the main reasons to use VPN, as an extension to your LAN.

[petenixon]

Thanks eduardo, i'm comfortable seeing private networks going across the tunnel, what's concerning is the source address of the echo request being 10.150.0.0 and destination address 10.201.84.0. Hosts cannot be configured with a subnet address?

[eduardopozo56]

Ohh sorry, i didn't  understand the "network address cannot be used" at first.

As you said, subnet addresses should not be used in hosts, from your Source/Destination IP's, only the source is a subnet address, being a /16, 10.201.0.0 would be the subnet address for the 10.201.84.0 host

Regarding the source ip that you are seeing, it is strange as you said, but taking into consideration that is a VPN tunnel, sometimes the VPN software or gateway spoofs the source ip when forwarding some packets, hiding the actual source host without affecting the routing for security.

[Richard Burts]

It is certainly true that a subnet address can not be assigned as the interface address of an IP host. And at first look you would think that a source address of 10.150.0.0/16 is invalid. But realizing that it came through a VPN makes me wonder if the remote side is doing address translation. As a translated address 10.150.0.0/16 would not necessarily be a problem. But I would hesitate to set up translation that way. My concern would be that the IP stack in some hosts would look at the address as they build a response and treat the address as an invalid destination address. So the safe thing would be to avoid addresses like this when doing translation.

HTH

Rick

[petenixon]

Thanks Richard.

(edit: the 10.201.84.0 is /24, not /16).

We aren't doing any translation across the VPN, however the remote end is not under our control and we are just seeing this traffic on our firewall (but as far as i'm aware, they aren't performing any translation either).

It's a very odd state of affairs. I am going to take a look at a packet capture shortly (out of curiosity more than anything), but until I work out what's going on, all ICMP echo requests from that subnet are being dropped.

[petenixon]

Checked the packet capture and the source address is from a Juniper firewall (our VPN endpoint) and the destination looks like an Intel based laptop.

Which makes even less sense. I was happier thinking this was sourced from the other side of the VPN...

The Juniper FW has the remote subnet configured on it for the encryption domain only, there are no other references to this subnet anywhere else on the fw.