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?
-
What about connecting to SSH after VP establishment ? :p You are right that this is caused because VPN overwrites the routing paths. What you can do is to keep your original paths untouched and just add the extra VPN path (Unless you want to use your VPS as proxy. That's another story). Which client do you use ? – Nikolaidis Fotis Dec 07 '14 at 13:11
-
What do you mean with "try to establish VPN connection on that VPS"? You're connecting from your machine to an Openvpn server on the VPS? Your VPS is connecting to an Openvpn server running on a third host? In this last case, such VPN connection is pushing back some routes? Also, please confirm there are no NAT translations to reach your VPS (the IP address configured on its interface is the same you're specifying in the SSH connection? – Damiano Verzulli Dec 07 '14 at 13:19
-
@NikolaidisFotis I'm not able to connect since VPN is running. I use openvpn client. There's an `--route-noexec` option to ignore routes pushed by the server but, as you mentioned, it doesn't help when I want to use VPN as proxy... – mic22 Dec 07 '14 at 22:06
-
@DamianoVerzulli the second option, yes routes are pushed (but I think it has to be done since I need that VPN to act like proxy to cloack original IP address of the machine), and no there's no NAT – mic22 Dec 07 '14 at 22:08
6 Answers
Let's consider following scenario:
- your VPS has a single ethernet interface, configured with IP address 4.3.2.1/24;
- your VPS can access the Internet via a default-gateway 4.3.2.254
- 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 9.8.7.6/24 with def-gw 9.8.7.254) you can successfully establish an SSH connection to 4.3.2.1. Hence both hosts 4.3.2.1 and 9.8.7.6 can succesfully reach each other.
Now, with such an SSH connection established, let's suppose:
- you launch an OpenVPN connection from your VPS 4.3.2.1;
- 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 (9.8.7.6) to VPS (4.3.2.1) will flow trough the previous, never changed, path;
- Traffic from VPS (4.3.2.1) to your machine (9.8.7.6):
- without the VPN (hence, initially) was routed through the 4.3.2.254 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 9.8.7.6 gw 4.3.2.254
where:
- 9.8.7.6 is your machine public IP address
- 4.3.2.254 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 :-)
![](../../users/profiles/251104.webp)
- 3,948
- 1
- 20
- 30
-
Thank you for your answer @DamianoVerzulli! Default gateway is unspecified. `route add` command with such 0.0.0.0 gw returns `SIOCADDRT: Invalid argument` – mic22 Dec 09 '14 at 21:20
-
That's what I get just after openvpn connects `[server] Peer Connection Initiated with [AF_INET]64.251.27.139:443; TUN/TAP device tun0 opened; do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0; /sbin/ip link set dev tun0 up mtu 1500; /sbin/ip addr add dev tun0 10.200.1.251/22 broadcast 10.200.3.255; ERROR: Linux route add command failed: external program exited with error status: 2` – mic22 Dec 09 '14 at 22:20
-
@mic22 : I wonder how def-gw of your VPS can be unspecified as in this case such VPS cannot reach anything outside of the local subnet (and this means that both your machine --being able to connect via SSH-- and OpenVpn server --being able to establish VPN-- should be "local" and, as such, quite useless!). BTW: when you're connected via SSH you can easily get def-gw with a "netstat -rn" (line starting with 0.0.0.0, second column) – Damiano Verzulli Dec 09 '14 at 22:21
-
`netstat -rn` result `0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 venet0` the VPS I'm using is an OVH basic option with Ubuntu 14.04 Server on board – mic22 Dec 09 '14 at 22:27
-
-
Ok. This sounds a strictly OpenVZ-related networking configuration that I'm not confortable with :-( So your VPS doesn't have a "strict" def-gw. Instead it simply send out everything on the lan virtual interface (venet0). So let's try to do the same, _after_ establishing the VPN, with your client-machine IP: let's tell the VPS to send out trough the venet0 interface all the traffic directed to you. Something like: "ip route add a.b.c.d/32 dev venet0" where a.b.c.d is your client-machine public IP address. – Damiano Verzulli Dec 09 '14 at 23:34
-
You need to add route-nopull
option (and remove redirect-gateway
if it exists) to your OpenVPN client's configuration file on your VPS.
That way connecting to a VPN server won't modify any routes on your VPS, so you would be able to set those you need by yourself.
![](../../users/profiles/306348.webp)
- 3,597
- 17
- 23
-
Hey, thanks for this advice, but now I cannot reach internet through the tun0. I suppose I'm missing a gateway. Any ideas how to add a gateway for tun0? Relevant part of ifconfig: `inet addr:10.56.10.6 P-t-P:10.56.10.5 Mask:255.255.255.255` – The Onin May 05 '17 at 16:34
-
You need to manually add a route to the VPN server itself via your default ISP gateway, then add default gateway via 10.56.10.5 for all other traffic – Anubioz May 05 '17 at 17:03
-
I'm sorry, what? I have no idea what you just said. Could you give an example ? – The Onin May 05 '17 at 17:27
-
Let me just clarify - I don't want to the default route to be via tun0, but I do need tun0 to have internet access. – The Onin May 05 '17 at 18:02
-
@Housemd hm you need to have internet access through tun0 yourself or you need clients connected via tun0 from other places to have internet access? – Anubioz May 05 '17 at 22:18
-
-
@Housemd So basically you want a single program to be able use another interface, while the rest of the system use a standard interface for making connections? Have a look at this https://superuser.com/questions/271915/route-the-traffic-over-specific-interface-for-a-process-in-linux – Anubioz May 06 '17 at 02:54
-
You can add this line: `route The.IP.To.Go 255.255.255.255` in the OpenVPN's configuration file if you only need to route a specific IP through the VPN connection, also with the `route-nopull` option mentioned in the answer. Source: https://superuser.com/a/628488 – dusan Sep 27 '18 at 12:14
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 screen
command.
(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.
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 autossh
Under your ssh client configuration
just add .ssh/config
Host *
ServerAliveInterval 300
ServerAliveCountMax 2
BatchMode yes
- BatchMode stands for auto-reconnect
- ServerAlive stands for Keeping Alive
![](../../users/profiles/187680.webp)
- 132
- 2
- 12
This can help:
put TCPKeepAlive=yes
in your /etc/ssh/sshd_config
From
man sshd_config | less +/'^ *TCPKeepAlive'
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 to
no''.
![](../../users/profiles/120473.webp)
- 1,150
- 9
- 15
-
I'v already had `TCPKeepAlive` option set to `yes` so that's not a proper solution – mic22 Dec 07 '14 at 22:12
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.
-
This is confusing, and the language appears to have it backwards. Wouldn't you want to add a route with the SSH target's IP address and the local workstation's default gateway? – rmalayter Nov 04 '15 at 15:17