3 ms·

Interesting. So from yours and the other comment, it sounds like the issue really comes down to not being able to force all applications to use the "VPN interfa

Interesting. So from yours and the other comment, it sounds like the issue really comes down to not being able to force all applications to use the "VPN interface", while still keeping the "hardware interface" functional so the VPN itself can use it. I can see why it can so quickly become a giant mess... Assuming it's the OS that needs to "fix" this, are there any changes either already made or in the works to better address this use case, or is a hardware VPN still going to be the only "real" way to securely tunnel a system for the foreseeable future?

dylz 9y ago
It's less that, it's more the fact that you're presenting a standard network connection. Software can do the equivalent of ifconfig | grep addr, software can print the routing table (and therefore get all gateways) A really basic thing to do would just be to drop all traffic not destined toward your VPN endpoint, so leaks would fail and/or be logged, but this still doesn't solve the fact that _other software running on your computer can enumerate all your interfaces for IPs and MAC addrs and gateways_ If you do it one layer up, you solve the software problem. Software and software on generally on same layer, so equally access, at least in usual conditions
magnat 9y ago
You can use custom kernel filter on Windows and iptables/netfilter on Linux to allow only one process to access physical interface. I've seen Cisco VPN Client (10 years ago or so) do it - apart from CVPND service, all traffic to/from ethernet was dropped. That included kernel stuff - to the point your PC didn't even respond to ARP packets from anything other than gateway. Of course, introducing custom kernel driver and/or your own mini IP stack is way harder to do in a safe way - that's why it's not usually included. As for Linux solutions - I haven't seen VPN client that used this technique, but I guess it's a lot easier, since all the required userland tools are already there.

dylz 9y ago

It's less that, it's more the fact that you're presenting a standard network connection. Software can do the equivalent of ifconfig | grep addr, software can print the routing table (and therefore get all gateways) A really basic thing to do would just be to drop all traffic not destined toward your VPN endpoint, so leaks would fail and/or be logged, but this still doesn't solve the fact that _other software running on your computer can enumerate all your interfaces for IPs and MAC addrs and gateways_ If you do it one layer up, you solve the software problem. Software and software on generally on same layer, so equally access, at least in usual conditions

magnat 9y ago

You can use custom kernel filter on Windows and iptables/netfilter on Linux to allow only one process to access physical interface. I've seen Cisco VPN Client (10 years ago or so) do it - apart from CVPND service, all traffic to/from ethernet was dropped. That included kernel stuff - to the point your PC didn't even respond to ARP packets from anything other than gateway. Of course, introducing custom kernel driver and/or your own mini IP stack is way harder to do in a safe way - that's why it's not usually included. As for Linux solutions - I haven't seen VPN client that used this technique, but I guess it's a lot easier, since all the required userland tools are already there.