[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Issue when 2 similar networks connect


  • Subject: Re: [Openvpn-users] Issue when 2 similar networks connect
  • From: Josh Cepek <josh.cepek@xxxxxxx>
  • Date: Thu, 06 Sep 2007 14:16:50 -0500
  • Openpgp: id=2E5A5127
  • Z-usanet-msgid: XID420LiFTRd0494X39

Craig Sturman wrote:

Our internal office network is numbered as a standard internal A class. (10.0.0.0/255.255.0.0).  I’m noticing a large number of hotels have been using this same internal network which, while the OpenVPN client says the user is connected, fails to pick up or contact our internal DNS servers and find the internal ip of whatever server it is attempting to contact (or perhaps OpenVPN does this on purpose because it realizes the overlap?).

[...]

 

Apart from renumbering our internal network (which I’m fine with doing as a last resort), is there an easier solution that would allow similar and non similar networks to connect without issue?  The following link mentions using some ipchain rules (which I assume can be translated over to iptables?) could be used for the rewriting?  Any help with this would be greatly appreciated.

 

http://www.debian-administration.org/articles/35#comment_1


Additional info: The server is using routing rather than bridging and everyone has their own set of generated keys.


Theoretically the OpenVPN server on your end could netmap the IP ranges you use to a different set of subnets that don't overlap with the one the client is connecting from.  This gets messy and I don't recommend doing it for a couple reasons:
  • You don't know which networks might be in use because the client might move to a new hotel/network which has a different range of subnets that cause different conflicts.
  • Any IP addresses configured on the mobile client to access your internal services (DNS & DNS replies, SMTP, POP, internal web sites, etc) won't be valid because all the IP's have been remapped.  Basically this is a huge headache and not worth the trouble.

Ideally you want to configure your internal networks as to avoid conflicts as much as possible, and using a 10.0.0.0/8 network is the way to insure you have as many conflicts as possible since any remote network using any subnet in this range is in conflict.  Unless you actually need 16.5 million IP addresses you should consider using much smaller subnets that fit the amount of devices connecting.  It's best to try and use networks that aren't as commonly used, so stay away from obvious networks like 10.0.0.0/24, 10.1.0.0/24, 192.168.0.0/24, 192.168.1.0/24, etc where it can be avoided.  I'd recommend looking at at the 172.16.0.0/12 network range since that's much less used, or perhaps something in the middle of the 10.0.0.0/8 range with as small a subnet mask as makes sense.  The goal here is to keep your subnets small and as unique as possible to minimize any chance of overlap.  This holds true not only for the virtual VPN network, but also any routes from your internal LAN that are pushed to clients via route statements.

However, even the best choices (such as the 172.19.250.0/24 network for one of my VPN's) can be in conflict if the client happens to be connected to an overlapping network (such as a poorly chosen 172.16.0.0/12 by an uninformed hotel.)  If you can't avoid an overlap there is a cheap trick you can employ by using a NAT-enabled router between the mobile client and the remote network.  This allows the client to connect to a non-overlapping network as configured on the LAN side of the router while the router deals with the communication to the would-be overlapping network.  This has a couple notable disadvantages, namely:
  • You can't use the remote network's DNS servers once you connect to the VPN (since the client routes them through the VPN rather than to the local router)
  • The client can't reach any of the overlapping devices on the remote network side while on the VPN (again, this is because the VPN routes are local and take priority over the default route.)  This may adversely affect ICMP requests/replies or access to services available on the remote network.

In short, when designing any network to be as VPN-friendly as possible, keep your subnets as unique and small as you can.

-- 
Josh

Attachment: signature.asc
Description: OpenPGP digital signature