BUG - SSL VPN Default Gateway Broke

I'm sorry but this just sounds like a recipe for disaster. It goes against all rules to have the same network subnet on both ends of a VPN tunnel, a routing nightmare, how is a device on one side supposed to know whether the other device is on the local network or the remote one? What if a device on the remote side happens to have the same IP address as something critical, say a domain controller or file server? Having the same subnet on both sides is a very, very bad idea. What if the remote side has other devices it needs to access locally, like a printer? Now it can't because the route sends traffic to another router which may be on a network with a device with the same IP but not the printer they hope to reach. One should never have to route traffic destined for the same subnet at all. What if the remote user has an IP address that is the same as one on the host network? How is a device on that network going to know traffic is coming from your remote user and not the device on its local network? I believe this is referred to as asymmetric routing, not good. I do realize these situations cannot be avoided at times, but some careful planning of the host network could have avoided this problem. Your best bet in a situation like this might be to use some form of NAT to translate your remote user's address to something else that doesn't conflict with the local subnet. That it doesn't work is a good thing, the Sophos VPN client is avoiding creating an otherwise dangerous and bad practice routing scenario.

First off this is not a site-site tunnel, the locations the remote user is at has the same IP Range as the office, the end users is using the SSL VPN Client on the PC to login to the work network, that is what the tunnel all option is for and is required for.

Same goes for being at a hotel if they use the same IP Range as your office location the VPN Client should be able to support that by using the tunnel all or use as default gateway.

First off this is not a site-site tunnel, the locations the remote user is at has the same IP Range as the office, the end users is using the SSL VPN Client on the PC to login to the work network, that is what the tunnel all option is for and is required for.

Same goes for being at a hotel if they use the same IP Range as your office location the VPN Client should be able to support that by using the tunnel all or use as default gateway.

Just because it works at a hotel doesn't make it a good idea, having the same subnet on both ends of a VPN is NEVER a good idea. As for the SSL VPN Client or SSL VPN site-to-site there is little difference between the two, one has a router at each end, the other has a router on one end and a PC running VPN client software at the other. Technically once you start defining static routes at the PC end the PC is acting as a router. The fact still remains that once you have two identical networks connected together across a VPN tunnel nothing good can come of it. Sure, it might work sometimes, until things start going haywire because two devices on either side of the tunnel share the same IP address. For example, say your PC at the remote end has the address 192.168.1.10, at the host end there is also a device, say a printer, which has the same IP. How will a device you are trying to communicate with from your remote PC know whether you are a PC on the end of a VPN tunnel or the printer that is on its own LAN? Short answer, it won't, it will look at it's ARP table and see the MAC of the local printer and route the packets accordingly. You might say, well won't it go to it's default gateway to find out where to send the packets? The answer is NO, the default gateway is there to route anything that is NOT on the local subnet, any traffic destined to the same subnet goes directly to the device, no routing required.