anon@randombox~$ netstat | grep 2222
tcp 0 208 randomserver.example:2222 1.2.3.4 ESTABLISHED
But then I noticed that on one of servers with dual IP addresses, the opposite thing was happening, and the ssh connection was being routed through the VPN, as it ought to be:
anon@randombox~$ netstat | grep 2222
tcp 0 208 randomnserver2.xx:2222 10.8.0.8:56789 ESTABLISHED
Checking my routing table, I realized the reason this happens is because any traffic destined for the VPN server's IP address will be routed through your default interface (ie when not connected to the VPN, let's say eth1):
anon@somebox:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.8.0.5 0.0.0.0 UG 0 0 0 tun0
10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0
10.8.0.5 * 255.255.255.255 UH 0 0 0 tun0
vpn.rando 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 1 0 0 eth0
There are of course very easy solutions to this issue. You could simply tweak the iptables on your server to only allow ssh through the VPN (tun/tap) interface, or if you have multiple IP addresses on your server, you could simply connect to a different IP than your inbound VPN uses. I'm sure you could also alter the routing table on your pc, but I cannot think of a way that would work as of this moment, because this is kind of just how VPN's work.
Perhaps a patch for OpenVPN could be written that ensures that only traffic destined for the VPN's gateway port is routed through the default interface. This way, you would not have these kind of leaks.
No comments:
Post a Comment