L2TP Routing Issue with Local Network
I'm at the St. Regis in Bora Bora (the same resort that was featured in the movie 'Couples Therapy'), and while it is beautiful in almost every way, they have a supernet on their wifi that is causing routing issues with me being able to route traffic over my L2TP vpn.
Their wifi is using 192.168.0.1 as the default gateway, which does not conflict with ours of 192.168.1.1, but because they are using the subnet mask 255.255.240.0, there ends up being a conflict that prevents any traffic (pings, etc) to route over the vpn.
Generally the quick and dirty trick I use to solve a routing issue is to simply delete the default gateway setting in windows using 'route delete 0.0.0.0 mask 0.0.0.0 192.168.1.1' after the vpn is connected and this forces all the traffic to go over the vpn. But the following command 'route delete 0.0.0.0 mask 0.0.0.0 192.168.0.1' does not seem to have the same effect. 
I'm not well versed enough with static routing to know what I'm doing wrong with the route command, but am confident there is a route change (or series of route changes) that will get this to work since the L2TP connects without an issue.
The Internet is pretty stellar as they have fibre optic right into the overwater bungalow and the speeds are ~30/30...I just need a solution to this routing issue and then I can remote back in to handle some urgent work. Thank you in advance for any assistance!
Comments
We usually recommend not using the very common 192.168.x.x addresses due to this.
For the L2TP client, you can try to add routes to the local machine, but Windows usually takes the ones it applied first as the winning route, so that's not generally helpful.
The WatchGuard IPSec client (which comes with a free 15 day trial) comes with a feature attempts to traverse duplicate networks like this. This would require setting up the IPSec VPN to use it, though.
Since L2TP is working within the constraints of the OS's client it's running on, the universal answer is going to be to use a less common network that's still inside the RFC1918 private addresses at home. That'll prevent overlaps like that if some other admin sets up their address space on very common spaces like you've encountered today.
-James Carson
WatchGuard Customer Support
Thank you for the reply. Unfortunately, none of that can be changed.
However, I did find the solution. There was an additional route for 192.168.0.0 that when deleted using 'route delete 192.168.0.0 mask 255.255.240.0' along with the previous route delete for the 192.168.0.1 default gateway allowed the vpn to work perfectly. I hope this helps someone else that's ever stuck in this situation.
Hi @Samir
That works too. (Some customers will make route add / dele scripts to change them. If you decide to do that just remember to run your bat file as admin so it has the right privilege.)
-James Carson
WatchGuard Customer Support