1

TLDR: Double-hop VPN on raspberry pi. Can ssh to and see samba shares of local devices over VPN. Can't get internet traffic over VPN. Not sure how to proceed.

My setup is a single Raspberry pi running openvpn and pi-hole. I have two instances of openvpn:

  • server.conf - VPN host over tun-incoming. This is working, I'm able to see VPN DNS requests on pi-hole.
  • outgoing.conf - connecting to a VPN vendor over tun-outgoing. Working locally. I'm able to see a new IP.

I'm mainly following this guide: https://www.comparitech.com/blog/vpn-privacy/raspberry-pi-vpn/ The idea is I should be able to (1) ssh, see shared files, etc. on all my devices at 192.168.*.* on my local network and (2) have internet tunneled through the VPN vendor. The first use-case is working fine.

I have tried this per the guide:

ip rule add from 192.168.1.166 lookup 101
ip route add default via 192.168.1.1 table 101

After, I lost ability to connect SSH over ipv4.

Below are some relevant outputs:

ip route list

pi@raspberrypi2:~ $ ip route list
0.0.0.0/1 via 10.1.11.5 dev tun-outgoing
default via 192.168.1.1 dev eth0 src 192.168.1.166 metric 202
10.1.11.1 via 10.1.11.5 dev tun-outgoing
10.1.11.5 dev tun-outgoing proto kernel scope link src 10.1.11.6
10.8.0.0/24 dev tun-incoming proto kernel scope link src 10.8.0.1
128.0.0.0/1 via 10.1.11.5 dev tun-outgoing
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.166 metric 202
199.229.249.184 via 192.168.1.1 dev eth0

ip rule list

pi@raspberrypi2:~ $ ip rule list
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

iptables -t nat -S

pi@raspberrypi2:~ $ sudo iptables -t nat -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -m comment --comment openvpn-nat-rule -j MASQUERADE

ifconfig

pi@raspberrypi2:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.166  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2604:2000:6aa0:c0d0::307  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::7a09:12ee:27ff:f6fc  prefixlen 64  scopeid 0x20<link>
        inet6 fd38:2d6b:a55b::111  prefixlen 128  scopeid 0x0<global>
        inet6 fd38:2d6b:a55b::307  prefixlen 128  scopeid 0x0<global>
        inet6 fd38:2d6b:a55b:0:3ed3:ce3b:88db:5070  prefixlen 64  scopeid 0x0<global>
        inet6 2604:2000:6aa0:c0d0:70cf:5710:52e:373e  prefixlen 64  scopeid 0x0<global>
        ether dc:a6:32:65:73:5d  txqueuelen 1000  (Ethernet)
        RX packets 48570  bytes 8636380 (8.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 55906  bytes 34181320 (32.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 331  bytes 27074 (26.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 331  bytes 27074 (26.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun-incoming: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.1  netmask 255.255.255.0  destination 10.8.0.1
        inet6 fe80::a8c2:d1fa:b798:f945  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 432 (432.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun-outgoing: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.1.11.6  netmask 255.255.255.255  destination 10.1.11.5
        inet6 fe80::9fe5:8e1:b1c0:86c5  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 24200  bytes 3403386 (3.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 30214  bytes 29464427 (28.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:65:73:5e  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
2
+50

TL;DR You don't need an IP rule. All you need here is another NAT rule for packets going out tun-outgoing interface.

Explaination: What is happening is that the VPN provider router (eg. 10.1.11.5 dev tun-outgoing) doesn't know how to reach back 10.8.0.0/24, so packets are dropped/lost.

This is due the fact that the network 10.8.0.0/24 is known (meaning that it's in the routing table) by raspberrypi2 router, but it's unknown to any other host not in the same VPN (such as LAN hosts and the external VPN provider).

Looking only at the second use case that you mentioned (use the VPN provider to surf the internet), in theory you have two ways to solve this:

  1. By configuring (statically/automatically) a route in each host that you need to reach from inside your VPN (tun-incoming)
  2. Or, by masking the IP using NAT

The first method is obviously not feasible in presence of external actors (the VPN provider), so you can solve this problem only by creating a NAT rule like this:

-A POSTROUTING -s 10.8.0.0/24 -o tun-outgoing -j MASQUERADE

This rule will mask all connections from your VPN 10.8.0.0/24 to the internet via VPN using the (source) IP address of the raspberrypi2, which is known by the VPN provider.

First use case (LAN access): For the first use case, you can (and actually are) still use the NAT method, but also method 2 can be applicable. To apply it, if raspberrypi2 is the default gateway of the LAN, you can simply remove the NAT rule and everything will work properly.

If rasperrypi2 is not the default gateway of the LAN, you can still apply method 2 by:

  • configuring a static route in the current default gateway of the LAN
  • or, configuring a static route in each host of the LAN

(both, obviously, pointing to raspberrypi2 only for the 10.8.0.0/24 subnet).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.