OpenVPN tunnel network overlapping LAN network
-
Hi.
My pfSense LAN network is 10.20.47.0/24
The VPN provider I use as OpenVPN Client (to Policy Route traffic with Firewall Rules) is using random /16 tunnel networks out of the 10.0.0.0/9 range.
So sometimes after reconnecting I get 10.20.0.0/16 as tunnel network and now it is overlapping my LAN range.
Could that lead into any problems?Thanks.
-
@henrymatthews97
Yes. Since they give you random addresses in 10.0.0.0, put your LAN in one of the other RFC1918 ranges. -
Thanks for your answer.
There is really no way without changing my LAN network?
What I really don't understand...when they assign me 10.20.0.0/16 everything seems working fine? The OpenVPN gateway stays online and I can policy route traffic out the VPN?! -
There are 256 subnets in 10.0.0.0 /16. So you have a 1 in 256 chance of being on the same subnet as the VPN. Most of the time you're fine, but on that one time when you're on the same subnet it will fail. The easiest way to deal with this problem is to avoid it, by not using something in 10.0.0.0 for your LAN.
-
@henrymatthews97 said in OpenVPN tunnel network overlapping LAN network:
Thanks for your answer.
There is really no way without changing my LAN network?
What I really don't understand...when they assign me 10.20.0.0/16 everything seems working fine? The OpenVPN gateway stays online and I can policy route traffic out the VPN?!Your 10.20.47.0/24 is more specific than the 10.20.0.0/16 , and will have precedence
/Bingo
-
So there is only a problem if they assign 10.20.47.x/16 to me?
I need to recheck. Mostly I have seen 10.20.0.x/16, for example 10.20.0.3/16 or 10.20.0.5/16 -
@henrymatthews97 said in OpenVPN tunnel network overlapping LAN network:
So there is only a problem if they assign 10.20.47.x/16 to me?
I need to recheck. Mostly I have seen 10.20.0.x/16, for example 10.20.0.3/16 or 10.20.0.5/16A /24 beats any /16 ... More specific
10.20.0.x/16 actually covers 10.20.47.x , but the /24 (defined by pfSense IF) in the route table wins
-
Okay, say they would assign me 10.20.47.3/16 as tunnel network IP.
It would break my OpenVPN connectivity but the LAN network would be fine? -
@henrymatthews97 said in OpenVPN tunnel network overlapping LAN network:
Okay, say they would assign me 10.20.47.3/16 as tunnel network IP.
It would break my OpenVPN connectivity but the LAN network would be fine?Yup ...
That would be an issue , as pfSense packets to 10.20.47.3 would go to the local lan .. No route beats a "Connected network" -
@bingo600 said in OpenVPN tunnel network overlapping LAN network:
10.20.0.x/16 actually covers 10.20.47.x , but the /24 (defined by pfSense IF) in the route table wins
Traffic for the local LAN won't even hit the routing table. The transmitting device will look at the interface address, destination address & subnet mask to determine that it's on the local LAN and then send directly to the destination MAC. What happens if the destination is through the VPN, but has an address that would normally be on the LAN? An arp request will be made, get no response and the connection will then fail or it may connect to a device on the LAN, rather than through the VPN.
The way to deal with this problem is to avoid it entirely, by using a different RFC1918 address block, as I mentioned above. Any other "solution" is nonsense.
-
@henrymatthews97 said in OpenVPN tunnel network overlapping LAN network:
e 10.0.0.0/9 range.
If they use 10.0.0.0/9 you could put your lan in the "high half" of the /8
-
If they are in fact using /9 and not /8, then use the other half. Regardless, it's still best to use different addresses. What happens if the ISP decides to go with /8? I have done a lot of networking in business environments. I have learned there are commonly used subnets, which should be avoided to prevent collisions. That includes 10. and 192.168 subnets. So, I put my networks on 172.16 to avoid problems.
BTW, this is just one example of many as to why we should move entirely to IPv6. These sorts of problems are caused entirely by using NAT to share addresses. Even with IPv6 Unique Local Addresses, the equivalent of IPv4 RFC1918, you're supposed to use a random number, out of a huge range, to select the ULA prefix. This is on top of the unbelievably huge Global Unique Address block, which eliminates the need for NAT. There are enough GUA addresses for every person on earth to have over 4000 /48 prefixes. That's 4000 x 2^72 or 4.72236648287e+21 addresses each!
-
I was afraid that the best option is to put my LAN in another range, but this would be a lot of work for me.
I also do not like the idea to have a VPN provider force me to change the range. Say I put my LAN network to 172.20.20.0/24
Now in a few months they choose to push 172.20.0.0/16 ... or I use a different VPN provider and they use 172.20.0.0/16 as tunnel net maybe.
Weird they push big ranges like /16 anyway.... -
@jknott said in OpenVPN tunnel network overlapping LAN network:
If they are in fact using /9 and not /8, then use the other half. Regardless, it's still best to use different addresses. What happens if the ISP decides to go with /8? I have done a lot of networking in business environments. I have learned there are commonly used subnets, which should be avoided to prevent collisions. That includes 10. and 192.168 subnets. So, I put my networks on 172.16 to avoid problems.
IMHO that's pure lottery
I have been using 172.16.x.x/12 ranges lots of times too.The OP mentioned 10.0.0.0/9 , not me
I think i see something similar w. my ExpressVPN aka. they use RFC1918 for link addresses.
Here's a "snip" from a DEB10 VM , that is connected via them.
vpn-01:~$ sudo route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ...SNIP... 0.0.0.0 10.141.0.35 128.0.0.0 UG 0 0 0 tun0 default 10.xxx.zzz.1 0.0.0.0 UG 0 0 0 ens192 10.141.0.1 10.141.0.35 255.255.255.255 UGH 0 0 0 tun0 10.141.0.35 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 85.www.22.65 10.xxx.zzz.1 255.255.255.255 UGH 0 0 0 ens192 128.0.0.0 10.141.0.35 128.0.0.0 UG 0 0 0 tun0 ...SNIP... vpn-01:~$IMHO the OP could just as well use the high 10.x.x.x/9
Or take the chance with the existing network, until proven otherwise.
Btw: Neat trick with the 0.0.0.0/1
