1

My problem:

I am using Ubuntu 22.04 with a VPN from ExpressVPN set up using their cli tool, they also provide an ovpn configuration file, so I can tweak the configuration as I please while maintaining their authentication infos.

Before I started using the VPN I forwarded port 22 on my home router and I was able to access the machine via ssh from outside my network.

Now, when the machine is connected to the VPN, I am not able to connect via ssh.

What I tried:

First I used tcpdump to ascertain that the problem was what I was thinking: the inbound connection comes in from the default interface connected to my router but the outbound packets are sent to the interface created by ExpressVPN/OpenVPN tun0.

Partial output of tcpdump:

19:17:22.488812 enp5s0 In  IP [src ip omitted] > 192.168.1.20.ssh: Flags [S], seq 2135016686, win 65535, options [mss 1400,sackOK,TS val 58875528 ecr 0,nop,wscale 9], length 0    
19:17:22.488853 tun0  Out IP 192.168.1.20.ssh > [src ip omitted]: Flags [S.], seq 2642908921, ack 2135016687, win 64900, options [mss 1310,sackOK,TS val 638298497 ecr 58875528,nop,wscale 7], length 0    
19:17:23.514229 tun0  Out IP 192.168.1.20.ssh > [src ip omitted]: Flags [S.], seq 2642908921, ack 2135016687, win 64900, options [mss 1310,sackOK,TS val 638299523 ecr 58875528,nop,wscale 7], length 0    
19:17:23.515183 enp5s0 In  IP [src ip omitted] > 192.168.1.20.ssh: Flags [S], seq 2135016686, win 65535, options [mss 1400,sackOK,TS val 58876582 ecr 0,nop,wscale 9], length 0    
19:17:23.515204 tun0  Out IP 192.168.1.20.ssh > [src ip omitted]: Flags [S.], seq 2642908921, ack 2135016687, win 64900, options [mss 1310,sackOK,TS val 638299524 ecr 58875528,nop,wscale 7], length 0    
19:17:25.515204 enp5s0 In  IP [src ip omitted] > 192.168.1.20.ssh: Flags [S], seq 2135016686, win 65535, options [mss 1400,sackOK,TS val 58878582 ecr 0,nop,wscale 9], length 0    
19:17:25.515227 tun0  Out IP 192.168.1.20.ssh > [src ip omitted]: Flags [S.], seq 2642908921, ack 2135016687, win 64900, options [mss 1310,sackOK,TS val 638301524 ecr 58875528,nop,wscale 7], length 0    
19:17:27.546040 tun0  Out IP 192.168.1.20.ssh > [src ip omitted]: Flags [S.], seq 2642908921, ack 2135016687, win 64900, options [mss 1310,sackOK,TS val 638303555 ecr 58875528,nop,wscale 7], length 0    

I tried following the instructions provided in the answers in this thread How to allow ssh into terminal after connecting to VPN server without success.

I can't understand why the proposed solution does not work.

In essence what I need is a way to keep connections opened from outside my network via my public IP on the interface that is assigned to that network and not to tun0.

Is it possible to do this by manipulating routes from the ovpn definition (or command line)? Or is it better to use iptables? Or maybe the route I added using the solution proposed was not correct?

When trying the solution proposed in the linked thread I added these rules and routes:

ip rule add from x.x.x.x table 128
ip route add table 128 to 255.255.255.0/24 dev enp5s0
ip route add table 128 default via 192.168.1.20

where x.x.x.x is the public ip when not connected to the VPN.

Here are the routes once connected to the VPN:

0.0.0.0/1 via 100.64.100.5 dev tun0 
default via 192.168.1.1 dev enp5s0 proto dhcp metric 100 
10.0.0.0/8 via 192.168.1.1 dev enp5s0 
100.64.100.1 via 100.64.100.5 dev tun0 
100.64.100.5 dev tun0 proto kernel scope link src 100.64.100.6 
128.0.0.0/1 via 100.64.100.5 dev tun0 
169.254.0.0/16 dev tun0 scope link metric 1000 
172.16.0.0/12 via 192.168.1.1 dev enp5s0 
173.239.199.150 via 192.168.1.1 dev enp5s0 
192.168.0.0/16 via 192.168.1.1 dev enp5s0 
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.20 metric 100

All these routes are automatically added once I connect to the VPN. Here are also the routes when not connected to the VPN, if they may help:

default via 192.168.1.1 dev enp5s0 proto dhcp metric 20100 
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.20 metric 100 

NEW ROUTES:

0.0.0.0/1 via 100.64.100.5 dev tun0 
default via 192.168.1.1 dev enp5s0 proto dhcp metric 100 
10.0.0.0/8 via 192.168.1.1 dev enp5s0 
100.64.100.1 via 100.64.100.5 dev tun0 
100.64.100.5 dev tun0 proto kernel scope link src 100.64.100.6 
128.0.0.0/1 via 100.64.100.5 dev tun0 
169.254.0.0/16 dev enp5s0 scope link metric 1000 
172.16.0.0/12 via 192.168.1.1 dev enp5s0 
173.239.199.206 via 192.168.1.1 dev enp5s0 
192.168.0.0/16 via 192.168.1.1 dev enp5s0 
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.20 metric 100
0

2 Answers 2

1

THe issue with the connection is return packets are going out of a differnt interface. The inbound packets are coming in through enp5s0 and going out via tun0.

The rules you have used should be changed.

  • Firstly, you need to change the first line to read "to" x.x.x.x. The way the rule is currently, effects only the packet when it has already arrived at the host (destination). Therefore it wont effect the packet. Changing it to "to" effects the interface/gateway the packet leaves the host and therefore will effect the source IP.

  • The second line of 255.255.255.0/24 is invalid, the highest unicast address is 223.255.255.254. Therefore the second line in the rules will never be matched.

The rules should be:

ip rule add to x.x.x.x table 128
ip route add table 128 default via 192.168.1.1 dev enp5s0 

That would fix your ssh issue.

Some addition notes on the routes:

0.0.0.0/1 refers to ips 0.0.0.1 - 127.255.255.254 - I dont believe this is what you were wanting. the address should be 0.0.0.0/0 or you can use the alias default. **Note fixing this route will route ALL traffic that does not match a longer prefix (a more specific route) will be routed via the VPN, including internet traffic.

6
  • I implemented the solution you proposed but the problem remains Jan 30 at 9:54
  • Can you please paste copy and paste the route table now? Also do anotehr tcpdump and confirm if the packets are still going out via the ttun or via the ethernet interface? Jan 30 at 15:03
  • I added the routes to the post to have nicer formatting. I also verified with tcpdump and same problem Jan 31 at 8:27
  • the route 0.0.0.0/1 and 128.0.0.0/1 via 100.64.100.5 dev tun0 is the issue, it is sending the traffic down your tunnel, these are strange routes to use. Can you remove it from your vpn config? or even as a test when you are connected to the VPN, run ip route del 0.0.0.0/1 and ip route del 128.0.0.0/1 to remove the route. To explain, this route is routing all traffic with a dst within the range of 0.0.0.0 - 127.255.255.255 down the vpn tunnel, the 128.0.0.0/1 is sending the rest of the traffic down the tunnel. therefore your default route is never matched Jan 31 at 16:30
  • Understood. I thought about that too but since these routes are set up by ExpressVPN cli tool when the machine is connected to the VPN I hesitated to modify them. As soon as I have time to look into the issue again I'll try the solution. Feb 1 at 9:18
0

I had the same issue with ProtonVPN, what I did was creating a static route for the source IP from traffic was coming from and then as destination the eth0 interface:

ip route add 2.3.4.5 via 4.4.4.4 dev eth0

Where 2.3.4.5 is our source IP, 4.4.4.4 is the gateway of our eth0 (default gateway), and eth0 is the interface.

1
  • That also works, but note doing it this way, ALL your internet will be using your home gateway, why the vpn is connected. Feb 1 at 16:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .