9

for my problem I searched a lot but did not find a feasible solution, so I thought to my self to place a question in here.

The problem:

I have a remote server (lets call it A) and a local computer (lets call it B), both running Ubuntu 14.04. I could establish a reversed SSH tunnel connecting A and B by doing so At server A: ssh -R 2014:localhost:22 userb@B At the local computer B: ssh -p 2014 usera@localhost

where user-a and user-b are two users at A and B, respectively.

Now, I connect A to a VPN. After the VPN connection is successfully established, the currently openning ssh session does not respond anymore. Also, I cannot ssh into A anymore until after I killed the VPN connection.

Is there a way to let both SSH and VPN be happy? Perhaps to separate the SSH session from VPN ? (I found something called split tunneling but did not really understand it). Could someone enlightens me on this?

Pragnesh Ghoda シ
  • 8,318
  • 3
  • 25
  • 40
Cuong Truong
  • 111
  • 1
  • 2
  • 5

2 Answers2

5

This may be a bit late, but ...

The problem is that the default gateway gets changed by OpenVPN, and that breaks your current SSH connection unless you set up appropriate routes before you start OpenVPN.

What follows works for me. It uses iptables and ip (iproute2). Below, it is assumed that the default gateway interface before OpenVPN is started is "eth0". The idea is to ensure that when a connection to eth0 is made, even if eth0 is not the default gateway interface anymore, response packets for the connection go back on eth0 again.

You could use the same number for the connection mark, firewall mark and routing table. I used distinct numbers to make the diffences between them more apparent.

# set "connection" mark of connection from eth0 when first packet of connection arrives
sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234

# set "firewall" mark for response packets in connection with our connection mark
sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 table 3412

# route packets with our firewall mark using our routing table
sudo ip rule add fwmark 4321 table 3412

===

UPDATE:

The above works fine for me on Debian Jessie. But on an older Wheezy system I have just found that I need to add "via" to the routing table entry:

# our routing table with eth0 as gateway interface
sudo ip route add default dev eth0 via 12.345.67.89 table 3412

There "12.345.67.89" must be the original non-VPN gateway.

John Doe
  • 151
  • 1
  • 3
1

VPN screws up your route table by modifying your default gateway toward the new tunnel interface. The funny thing is that you can't initiate a new ssh connection afterward. So you are saying that ssh -R 2014:localhost:22 userb@B wouldn't connect when going through your VPN?

What is traceroute saying? (Once VPN loaded). Don't you have any kind of port limitation with your vpn provider? If you are using a commercial one I mean.

--- EDIT

Your best try would be, while connected to VPN, from server A :

telnet B 22

To see if you can make a simple TCP SYN to destination. Anyway I'd be surprised hidemyass wouldn't let your ssh traffic going through.

To recap, your VPN is configured on your server? You are trying to connect from your server B to your client A, through your VPN? You should be able to traceroute to your VPN public address (which you can get with whatismyip.com for example).

You could check as well on your client for remote packets, coming from your server :

tcpdump -nnXs 0 -i eth0 host ip.of.vpn

wsteven
  • 67
  • 1
  • 8
  • thanks wsteven! The 'ssh -R 2014:localhost:22 userb@B' was executed before I connect server A to the VPN. After VPN is loaded, I cannot ssh into A from B anymore. Im not sure about port limitation. I am using HideMyAss VPN if that helps? – Cuong Truong Jul 11 '14 at 13:00
  • After VPN loaded, traceroute from B to A still works well (i.e., arrive at A). But traceroute from A to B does not, I think! (the console displays only a bunch of lines of '***' and not useful info). – Cuong Truong Jul 11 '14 at 13:15
  • 1
    I found the problem, which is very simple! Sorry it was my fault! The problem was DNS related. After VPN is load, my ISP's DNS cannot resolve any address anymore. Atfer replacing it with Google DNS (8.8.8.8, 8.8.4.4) I could establish the reserved SSH tunnel. However, what I really wanted is to establish the SSH tunnel before VPN is loaded and still be able to remotely work at A from B via my currently established SSH session while VPN is being loaded and after VPN is loaded. Is there a way to separate the SSH tunnel from VPN? – Cuong Truong Jul 14 '14 at 08:45
  • Yep, ask openvpn to load a route on your client to send traffic through your regular interface instead of tun0. Not sure you can do this with openvpn conf file, but you could instead run a script after connection is up to add a static route. Something like : up /path/to/script.sh With a route add -host ip.to.B dev eth0 Or if you have dynamic IP on your client : route add -net ip.of.net netmask 255.255.255.0 dev eth0 – wsteven Jul 14 '14 at 16:32
  • I suggest that you post an "Answer" to this thread, since you found it, so that the thread will explicitly show as having an "Answer." ### The basic reason why OpenVPN is messing-up SSH is that it is setting routes (either in the `config.ovpn` file *and/or* "pushed" from the server) that might be disrupting the existing SSH connection. (It can push DNS-changes, too.) You'll have to look at least at the OpenVPN logs to see what commands have been executed. – Mike Robinson Aug 04 '16 at 21:18