GNOME Bugzilla – Bug 652003
Option to not fall back to unencrypted if VPN fails
Last modified: 2011-06-09 14:43:28 UTC
NM needs an option to only let apps communicate to the outside via VPN. Right now, if a VPN tunnel breaks down, apps will happily use the underlying connection, let's say the unencrypted WiFi you are forced to use in a hotel... This could be exposed as an option in the VPN options but I think it should be the default and you should be notified and given the options to try to reestablish the VPN or continue unprotected. Until this choice is made, no trafic should be able to move outside.
Btw, there is *no* indication that the VPN broke down if for example the nm-pptp-service crashes. All that happens is that the "VPN Connections" slider moves from ON to OFF in the shell menu.
Yes, this would be part of the enhancements mentioned in the TODO file and in bug 560471. The base connection would either be torn down or NM would mark itself offline. However, this isn't a substitute for applications being smart about which connections are up and which connections to use for certain network resources. Applications like your work email should remember the connection UUID of your work VPN and go offline when NetworkManager indicates that the VPN connection has terminated. IRC/Chat programs should allow a certain IRC server to be tagged with a connection UUID of your VPN connection and terminate the chat when the VPn connection goes down. This is the only way to make it completely foolproof. Otherwise, if you forget to close your chat and you go home and then NM says it's online, now your apps are communicating over an unsecure channel. Again, apps *also* need to be smart, because there's only so much NM can do here. NM can provide the information and enforce some policy, but it depends on applications to also make sure that the resources they require are actually behind a secure tunnel, because only the applications are aware of the specific resources they require and the security restraints of those resources; NM is not. *** This bug has been marked as a duplicate of bug 560471 ***