Craig Sturman wrote:
Our internal office network is numbered as a
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,
OpenVPN client says the user is connected, fails to pick up or contact
internal DNS servers and find the internal ip of whatever server it is
attempting to contact (or perhaps OpenVPN does this on purpose because
realizes the overlap?).
Apart from renumbering our internal network
fine with doing as a last resort), is there an easier solution that
similar and non similar networks to connect without issue? The
link mentions using some ipchain rules (which I assume can be
to iptables?) could be used for the rewriting? Any help with this
be greatly appreciated.
Additional info: The server is using routing
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
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
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,
- 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.
Description: OpenPGP digital signature