I am surprised that not more vendors have solved this issue. You will often see solutions for where the user’s IP space overlaps with the client pool given out, e.g here, here and here.
An example would be client pool is 10.10.0.0/16 and the hotel network you are on it 10.10.0.0/22. The most common solution given is to create a separate profile with a different ip pool.
However, there is another similar issue, that even though haven’t seen to often, is still a concern. Let’s say your client pool is 10.10.0.0/16 and your hotel network is 172.16.0.0/22. Now you have no problem connecting, but you will have a problem connecting to a server in your datacenter at 172.16.1.100. That would once again route internally, and you have the chance of blackhole a large part of your network. I know that one vendor said they had a solution for this ( the vendor escapes me.) There claim was that every IP would be available except for the IP of the device and the IP of the default gateway. However, most seemingly do not. When evaluating client vpn’s, keep this in mind.
You can overcome some of these issues by sending smaller routes, but then you would have to know which smaller routes to send. In the example above, you would need to know to send 172.16.0.0/23 and 172.16.2.0/23, which is a good solution for a short fix for a client having an issue in a hotel. You can also increase your odds of not overlapping by using IP in your DC that is not likely to be used in a home/hotel. So stay away from 192.168 and use less used 10.X ip space, like say 10.189.0.0/24.
Or you know, learn to NAT.
Mike,
Thanks for commenting.
Though I am not sure how this will help you? Would you NAT the server IP with destination NAT? That would be just as likely to overlap as the original IP with complexity of connecting dual IP space. Source NAT’ing wouldn’t help as you would not get out of the hotel in this scenario.
I should have included one such solution the vendor can provide. In each scenario provide 4 extra routes. The first two is a /24 towards the traditional default gateway and a route to the default gateway itself. The next two would be to split the current network in half and let the more specific route choose to go over the tunnel, in the above scenario it would be 172.16.0.0/23 and 172.16.2.0/23. You would only blackhole 2 IPs, yours and your default gateway.
Hopefully that articulates the issues a bit better.