SSLVPN Forced Tunneling Exceptions

gullal

For some of our clients that require forced tunneling for specific applications, it would be nice to be able to customize exceptions for situations like what is described in this Microsoft article.

https://techcommunity.microsoft.com/t5/office-365-blog/how-to-optimize-stream-amp-live-events-traffic-in-a-vpn-scenario/ba-p/1439767

james.carson

Hi @gullal

In your situation, I'd suggest using the "specify routes" option in SSLVPN, and just supernet around the IPs you want to except.

If you prefer, you can also change the route table on the local machine by using the 'route add' command after it's connected.

Flo_Paris

Would be great to be able to put SSL-VPN tunnel exception using target domain name, not only IPs...

SiAccordDS

I would LOVE to have this as a feature! With split tunnel VPN being the most risky configuration and the use of Microsoft 365 hugely increasing, the Optimize endpoints in 365 need to be put in as exceptions.

Supernetting the whole of the Internet apart from quite small 365 IP ranges is a lot of routes. It would be far easier and better performing to have a few exceptions rather than hundreds of inclusions.

Tristan.Colo

I will be surprised if WG will be able to do this... all vpn providers I am aware of don't have this as a feature so!

I imagine it has to do with how the default route is programmed.

Full tunnel sticks a default route to the VPN, whereas split tunneling as a list of routes to the VPN... to do the 365 piece would require the ability for the SSL VPN to add a route that goes out your NIC... but if you have a Wireless and Physical NIC which NIC would it do and would it get removed afterwards?

IE: The reason the tunnels work a certain way is that the VPN only controls routes through the VPN... it would need to be able to programmatically stick the 365 routes on your correct NIC and then leave when done... not sure if this will be technically doable without the SSL VPN needing to do a lot of weird routing shenanigans and then remove those routing shenanigans when done...

james.carson

While I absolutely agree that this is a good idea (on paper) current OSes may be a limiting factor.
When SSLVPN (or any of the other VPNs for that matter) connect, they modify the route table for that PC. You can see this in Windows by typing 'route print' on the command line.

The issue with using FQDNs is that they change, and the list of them when you do a forward lookup may not be all-inclusive. Things get even more complicated when the service is running in the cloud (for example, in an AWS bucket on a shared IP with other cloud services.)

Feedback has been forwarded to the team that maintains the VPN and VPN clients, but for now the best way to do this will be via custom route -- and just supernetting around the IPs you don't want to traverse the VPN.