I encountered an issue that I can't deal with. When I'm logged onto an VPS over SSH and try to estabilish VPN connection on that VPS, the SSH connection between VPS and my machine get lost. I assume that's because routing got changed by VPN settings. How to prevent that?
Let's consider following scenario:
- your VPS has a single ethernet interface, configured with IP address 126.96.36.199/24;
- your VPS can access the Internet via a default-gateway 188.8.131.52
- your VPS has not yet activated any OpenVPN connection; hence there are no tun interface active
In such a scenario, from your machine (let's suppose your machine is 184.108.40.206/24 with def-gw 220.127.116.11) you can successfully establish an SSH connection to 18.104.22.168. Hence both hosts 22.214.171.124 and 126.96.36.199 can succesfully reach each other.
Now, with such an SSH connection established, let's suppose:
- you launch an OpenVPN connection from your VPS 188.8.131.52;
- as such, a new tun0 interface will be dinamically configured (let's suppose it will be assigned a 10.10.10.2 IP, with a 10.10.10.1 PTP).
At this stage:
IF no route will be pushed from remote OpenVPN server to your local VPS, then nothing will change in term of routing, and your SSH connection will survive with no problems at all. In this case, the only traffic traversing the VPN is the one directed towards the remote OpenVPN Server (10.10.10.1);
IF remote OpenVPN server will push back some route, and expecially if VPS default-gateway will be replaced with 10.10.10.1 (remote OpenVPN endpoint), THEN you're having problems. In this case you're tunneling ALL the outgoing IP traffic (with the exception of OpenVPN itself) within the VPN.
In this second case (replacing def-gw right after establishing VPN connection), your previous SSH connection will "hang", due to asymmetric routing:
- Traffic from your machine (184.108.40.206) to VPS (220.127.116.11) will flow trough the previous, never changed, path;
- Traffic from VPS (18.104.22.168) to your machine (22.214.171.124):
- without the VPN (hence, initially) was routed through the 126.96.36.199 gateway;
- after the establishment of the VPN link, with related def-gw replacement, is routed through the VPN (10.10.10.1).
In other words: as soon as the VPN link is established, your return route from VPS to your machine is going to change and... this is not a good thing (several network devices, along the return-path, might recognize such asymmetric path and simply drop packets).
Furthermore, chances are high that your remote OpenVPN server is acting as a NAT-box: all the traffic coming from the VPN will be NATted with the public IP-Address of the remote OpenVPN Server. If this is true, than things are no more... "not good", but definitely "bad", as for your SSH connection: return traffic, in addition to get back along a different route, is coming back to your machine with a different source IP (the one of the public interface of the VPN server).
How to solve this problem?
Quite easily, indeed.
Simply instructing your VPS server to not route traffic to your machine along the VPN, but, instead, relying on previous route. It should be as easy as adding, before starting OpenVPN:
route add -host 188.8.131.52 gw 184.108.40.206
- 220.127.116.11 is your machine public IP address
- 18.104.22.168 is the original default gateway of your VPS.
P.S.: by providing a much more detailed question, you would have gotten a much quicker answer :-)
I had this problem and tried all of the recommended solutions, and still, my problem wasn't solved!
After many attempted solutions, I used the
(my VPN client is cisco-any-connect).
$ screen -R VPN $ openconnect -b "your server"
After providing your credential, press ctrl+a+d immediately and back to your session.
This can help:
TCPKeepAlive=yes in your
man sshd_config | less +/'^ *TCPKeepAlive'
Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the connection or crash of one of the machines will be properly noticed. However, this means that connections will die if the route is down temporarily, and some people find it annoying. On the other hand, if TCP keepalives are not sent, sessions may hang indefinitely on the server, leaving ``ghost'' users and consuming server resources.
The default is
yes'' (to send TCP keepalive messages), and the server will notice if the network goes down or the client host crashes. This avoids infinitely hanging sessions. To disable TCP keepalive messages, the value should be set tono''.
Personally I prefer all connections to SSH to be routed through VPN. In case of active ssh connection before VPN established, it has to reconnect because of the route changed.
I recommend to use
Under your ssh client configuration
Host * ServerAliveInterval 300 ServerAliveCountMax 2 BatchMode yes
- BatchMode stands for auto-reconnect
- ServerAlive stands for Keeping Alive
Once after connecting VPN, ssh getting disconnected because, ssh traffic from the server going via VPN server. So to avoid this run the following command before connecting VPN.
route add -host your-machine-public-ip gw Server-gatway-ip dev eth0
your-machine-public-ip : IP of your machine from where you are doing SSH. Server-gatway-ip: Gatway/router's IP of that server
The above command will redirect the traffic via the given gateway not through VPN Server.