SSH connection screwed up after VPN connection established [closed]

Question

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?

Answer 1

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.

Answer 2

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