persistent SSH connection while connecting to VPN

Question

I have a Linux machine on the intranet which I can only access via SSH. This machine needs to connect to a VPN using OpenConnect; however when I do that, I get disconnected from the SSH session since the intranet's IP is no longer valid.

I can reconnect to it from within the VPN using the IP it got assigned, but that IP changes every time the VPN is connected. I don't have control over any of the networks, only this machine.

Is there a way to keep the SSH connection alive while connecting to the VPN?

---

openconnect requires a --script argument which takes a script to configure routing. Without it the connection succeeds, but no names are resolved and the intranet's IP remains valid.

I'm currently using Ubuntu's default /etc/vpnc/vpnc-script. I'm good with shell scripting but I know very little about networking. If I have to modify that, I'll need some reference about what or how to change it.

Answer 1

is there a way to keep the SSH connection alive while connecting to the VPN?

No. That system's routing changes dramatically when you connect to the VPN, which breaks all established TCP sockets.

You should look into using a terminal multiplexer like screen or tmux in your ssh session - that way you can have a persistent shell that you can re-connect to.

Answer 2

General Answer

You should use --script and --script-tun options of openconnect and provide a custom vpnc-script. A good starting point is the vpnc-script distributed already with your openconnect, For Example on OSX(HomeBrewed openconnect) it is located at /usr/local/etc/vpnc-script.

Note that according to openconnect official documentation:

OpenConnect just handles the communication with the VPN server; it does not know how to configure the network routing and name service on all the various operating systems that it runs on.

To set the routing and name service up, it uses an external script which is usually called vpnc-script.

---

Better Solution

There is already a good project called ocproxy which acts as a proxy server for openconnect, hence the name ocproxy(OpenConnectProxy).

ocproxy is a user-level SOCKS and port forwarding proxy for OpenConnect based on lwIP. When using ocproxy, OpenConnect only handles network activity that the user specifically asks from proxy, so the VPN interface no longer "hijacks" all network traffic on the host.

Example OpenConnect Command:

echo $1 | sudo openconnect -u $2 -d --timestamp -v --passwd-on-stdin --script-tun --script "ocproxy -D $3 -v" $4

Replace:

• $1 with: OpenConnect Password
• $2 with: OpenConnect Username
• $3 with: Desired Socks5 Proxy Port
• $4 with: OpenConnect Server Address

Answer 3

You may want to look into what is in the iptables, which handles packet filtering within the kernel. I use openconnect from the other direction, and the default setting is to remove access to the standard interfaces in favor of the newly created VPN interface. The first thing to do is figure out what routes are being created by the VPN connection. Then you can write a script to handle the gateway and routes, and then finally flush the iptables and clear the VPN "chain" (term used in iptables). I have a script that looks something like:

IPADDR=NN.NN.NN.N
DESIREDNET1=MM.MM.MM.MM
GATEWAY_LINE=$(netstat -rn | grep ${IPADDR})
GATEWAY=$(echo "$GATEWAY_LINE" | awk '{print $2}')
GATEWAY_DEV=gw
if [ "$GATEWAY" = "*" ]; then
    GATEWAY=$(echo "$GATEWAY_LINE" | awk '{print $8}')
    GATEWAY_DEV=''
fi
# add custom routes
route add -net $DESIREDNET1 netmask 255.255.0.0 dev cscotun0
...
# reset the default route
route del default
route add default $GATEWAY_DEV $GATEWAY

# flush iptables to clear the ciscovpn chain
iptables --flush
iptables --delete-chain
# Add out own nameservers back
if [ -f /etc/resolv.conf.vpnbackup ]
then
   cat /etc/resolf.conf /etc/resolv.conf.vpnbackup > /etc/resolv.conf
   echo "nameserver $GATEWAY" >> /etc/resolv.conf
fi

You'll need to copy the /etc/resolv.conf to /etc/resolf.conf while off the VPN to be able to add back the 'normal' settings.

Good luck.

Answer 4

I think the reason is that when your linux server make VPN connection, it routes all traffic through gateway in remote network. You can make your SSH alive if you config your VPN client only use remote gateway for communication with remote network.

I don't use openconnect, but in openvpn, you can tick in use this connection only for resources on its network in VPN configuration.

Answer 5

A workaround this issue is connecting to the same VPN server on both machines involved in the terminal connection.

It works for me.

Answer 6

If you are for example in a VPS and you able to create a mini VPS in the same datacenter, and also to provide a local IP in each of the two VPSs, you can make a tunneled SSH connection using the mini VPS as the tunnel. This way you can connect to the target VPS even when it is connected to a VPN.

To connect remotely using SSH:

• connect the internal (LAN IP) of the target VPS (the one that connects to the VPN)
• using as a tunnel the mini VPS - so connect to the external IP of the mini VPS

So the prerequisites for this is:

1. to be able to create an additional VPS in the same network
2. to assign to both machines a local additional IP

This is easy and feasible in popular Clouds like DigitalOcean, Linode etc

Answer 7

I've had success using vpn-slice. It is made for the exact purpose of limiting what gets routed over the VPN: https://github.com/dlenski/vpn-slice

sudo pip3 install vpn-slice or brew install vpn-slice

The vpn-slice command takes as arguments the specific hosts and/or subnets which you want to route through the VPN. Everything else is left intact.

sudo openconnect https://vpn.example.org --script 'vpn-slice --dump --verbose vpn-specific.host 10.13.37.0/24'

This is really useful when I need to connect to only a handful of services over a VPN, but want regular internet & LAN access to keep working. And it has the added benefit of not breaking my SSH connection (although you may want to tweak the settings locally first).

You can also exclude subnets like %10.13.37.0/24, automatically route the VPN's default subnet with --route-internal, etc. See vpn-slice --help for more.