Yes, "work" VPNs, site-to-site and many other topologies don't change the default route, but "privacy" VPNs like Mullvad usually do – there is no group of hosts to route traffic for other than simply "the entire internet".
That said, I'm aware of at least one that tries to support an "exempt/excluded hosts" feature, but it does this via some hack using its local DNS resolver and modifying the routing table on the fly, which does not work reliably.
Interesting! Is that actually the letter of the specification, or a common/industry-standard interpretation? I hate VPN setups like that; it often makes videoconferencing, browsing of non-corp sites etc. unnecessarily slow.
It's the letter of the specification, unfortunately:
> 3.13.7 Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
> DISCUSSION
> Split tunneling might be desirable by remote users to communicate with local system resources such as printers or file servers. However, split tunneling allows unauthorized external connections, making the system more vulnerable to attack and to exfiltration of organizational information. This requirement is implemented in remote devices (e.g., notebook computers, smart phones, and tablets) through configuration settings to disable split tunneling in those devices, and by preventing configuration settings from being readily configurable by users. This requirement is implemented in the system by the detection of split tunneling (or of configuration settings that allow split tunneling) in the remote device, and by prohibiting the connection if the remote device is using split tunneling.
And yep, it does indeed cause all of the problems you describe.
Yes, "work" VPNs, site-to-site and many other topologies don't change the default route, but "privacy" VPNs like Mullvad usually do – there is no group of hosts to route traffic for other than simply "the entire internet".
That said, I'm aware of at least one that tries to support an "exempt/excluded hosts" feature, but it does this via some hack using its local DNS resolver and modifying the routing table on the fly, which does not work reliably.
Lucky you. Any companies that have to follow NIST SP 800-171 have to configure their VPNs to reroute all traffic.
Interesting! Is that actually the letter of the specification, or a common/industry-standard interpretation? I hate VPN setups like that; it often makes videoconferencing, browsing of non-corp sites etc. unnecessarily slow.
It's the letter of the specification, unfortunately:
> 3.13.7 Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
> DISCUSSION
> Split tunneling might be desirable by remote users to communicate with local system resources such as printers or file servers. However, split tunneling allows unauthorized external connections, making the system more vulnerable to attack and to exfiltration of organizational information. This requirement is implemented in remote devices (e.g., notebook computers, smart phones, and tablets) through configuration settings to disable split tunneling in those devices, and by preventing configuration settings from being readily configurable by users. This requirement is implemented in the system by the detection of split tunneling (or of configuration settings that allow split tunneling) in the remote device, and by prohibiting the connection if the remote device is using split tunneling.
And yep, it does indeed cause all of the problems you describe.