In answer to what Balaij describes in his "use case 3" (inhttps://bugs.launchpad.net/ubuntu/+source/vpnc/+bug/124663/comments/23):
That is precisely what enterprise networks don't want to happen, because it's a security nightmare. If I had a user trying this on my employer's remote access VPN, I'd have the Chief Security Officer all over his back. If the VPN Tunnel is up, your system becomes part of the enterprise network, and therefore must use any internet access facilities and services (DNS Servers that can resolve internet names, virus scanning proxy servers etc.) as if the system were connected to the internal network. That of course is true if we are talking of "full integration", which I consider the normal use case. There are others, where an enterprise gives VPN access to a customer or contractor. Here, the VPN Tunnel must not give full access to the internal network, but only a few selected hosts. In that case, a proper configuration should seed out a few bits of routing information to the clients and leave their routing config untouched otherwise. Yet, there should be a network firewall protecting these allowed hosts against the VPN device where contractor's tunnels terminate. On a "full integration" scenario, allowing traffic to bypass the tunnel becomes a violation of security policies - it is equivalent to having a laptop plugged into the wired enterprise LAN and it's WiFi NIC associated with the coffee shop's public WiFi donwstairs. That is why having the default route point to a next hop beyond the tunnel interface is - IMHO - the correct behaviour, and why this is a feature, not a bug. It's kind of disturbing that no one bar the orginal poster has ever shown the output of "netstat -nr" in this thread. Adding a second default route is somewhat questionable - you'd need a (summary) static route for your enterprise network on the tun0 interface and a single default route towards your internet router. Mutliple default routes always cause confusion. Here's how to do it manually: 1.Remove default-through-tunnel route: sudo route delete 0.0.0.0/0 gw 0.0.0.0 tun0 2. Add route for enterprise network (possibly multiple, ask your enterprise's network admin for info about <network>/<prefix>) sudo route add <network>/<prefix> gw 0.0.0.0 tun0 3. Add new default route, where <local router> and ethX are your local LANs default gateway and ethX the interface connecting to it: sudo route add default gw <local router> ethX Current (8.10) network-manager-vpnc even allows you to add these static routes via GUI, and while doing so, leaves the default route as it was before. However, you still have the problem of DNS: /etc/resolv.conf is rewritten to use the enterprise network's DNS servers, which might be a "hard" requirement if you wanted to connect to systems whose names can only be resolved by their DNS. If these can also resolve internet names, you're lucky, even if somewhat hampered by possible DNS lookup delay, because lookup requests go through the tunnel (which might have it's other end somewhere far away), while your normal web request still uses your local internet access. If however the enterprise's DNS can't resolve internet names, you'll get stuck: manually rewriting /etc/resolv.conf to use some local DNS can help, but then you'll probably lose visibility and resolve-ability of enterprise host names... Again: I consider it a feature, not a bug. If you require other scenarios, you can work around it. -- No default internet traffic after connecting to VPN https://bugs.launchpad.net/bugs/124663 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
