Multiple VPN connections

sinan92 · December 9, 2021, 12:00am

I'm trying to set up two OpenVPN connections in combination with pbr. The first I got to work so my whole network goes through the VPN1 now. When I set up the second I can't access the internet when I get on it.

My OVPN configs are like the following:

VPN1

client
dev tun
proto udp
remote 82.**.**.** 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-128-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3

VPN2

client
dev tun1
proto udp
remote 109.**.**.** 1195
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3

I created two interfaces. tun0 and tun1 both are identical to each other.Unmanaged and zone set to wan.

My server config:

VPN1

local 82.**.**.**
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
status openvpn-status.log
client-to-client
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
route 192.168.1.0 255.255.255.0
keepalive 10 120
cipher AES-128-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify
client-config-dir client-config

VPN2

local 109.**.**.**
port 1195
proto udp
dev tun1
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.9.0.0 255.255.255.0
status openvpn-status.log
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
client-to-client
push "route 10.9.0.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
route 192.168.1.0 255.255.255.0
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify
client-config-dir client-config

Tracert reaches 10.9.0.2 but goes nowhere after that. "Desination unreachable" while it should be going to the internet from there.

Why does it not work once I start the second VPN?

vgaetera · December 9, 2021, 8:09am

https://docs.openwrt.melmac.net/vpn-policy-routing/#openvpn-tunnel-configured-with-ovpn-file

sinan92 · December 9, 2021, 9:41am

Thank you. That feels like a step closer and this feels clean. But unfortunately it did not work in the case of tun1.

Current situation (Service gateways):

wan/eth0.2/192.168.178.1 ✓
tun0/10.8.0.2
tun1/10.9.0.2

wan/eth0 works perfectly. So does tun0. But once I connect to tun1 I have no internet connection.

Tracert result:

  1    <1 ms    <1 ms    <1 ms  OpenWrt.lan [192.168.1.1]
  2    37 ms    39 ms    38 ms  10.9.0.1
  3     *        *        *     Request timed out.
  4     *        *     ^C

Is it right for me to set VPN1 on dev tun and VPN2 on dev tun1? I'm not sure if that name should be changed there. I did add interface tun1 but I did not know how else to let OVPN2 know that it should connect to tun1. Am I supposed to have different settings on the tun1 interface maybe?

vgaetera · December 9, 2021, 9:47am

You certainly need to declare both VPN network interfaces and assign them to the WAN firewall zone.
Also specify each device name with explicitly numbered suffix in the OpenVPN configs.

sinan92 · December 9, 2021, 9:51am

In the sake of completion I will show you my interface settings.

tun0:

tun1:

sinan92 · December 9, 2021, 9:58am

vpn1 is now set as dev tun0 and vpn2 is set as tun1 on both client and server side but unfortunately still no luck. Both interfaces are assigned to the wan zone.

My policy settings:

The guy in red has no internet connection.

sinan92 · December 9, 2021, 10:21am

I just started the server manually and saw this:

Thu Dec  9 10:15:55 2021 Oyster/84.**.**.**:40801 MULTI: Learn: 10.9.0.2 -> Oyster/84.**.**.**:40801
Thu Dec  9 10:15:55 2021 Oyster/84.**.**.**:40801 MULTI: primary virtual IP for Oyster/84.**.**.**:40801: 10.9.0.2
Thu Dec  9 10:15:56 2021 Oyster/84.**.**.**:40801 PUSH: Received control message: 'PUSH_REQUEST'

Am I supposed to open that port? I configured port 1195 what is port 40801? Could that be something?

sinan92 · December 9, 2021, 10:43am

In case something is wrong with my zone settings:

trendy · December 9, 2021, 11:47am

In the case of VPN2 the other end is responding on the traceroute, therefore you need to verify why isn't server2 forwarding the packets further down. Maybe you have not applied masquerading?

sinan92 · December 9, 2021, 12:24pm

Good point. I also expected the problem to be on the server side since it can reach the server. But the server doesn't seem to direct the call towards the internet. I did check all the settings I know I can check and I will post the configs below.

iptables --list-rules:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -p udp -m udp --dport 1195 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.9.0.0/24 -j ACCEPT

/etc/systemd/system/openvpn-iptables.service

Before=network.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/iptables -t nat -A POSTROUTING -s 10.9.0.0/24 ! -d 10.9.0.0/24 -j SNAT --to 109.**.**.**
ExecStart=/usr/sbin/iptables -I INPUT -p udp --dport 1195 -j ACCEPT
ExecStart=/usr/sbin/iptables -I FORWARD -s 10.9.0.0/24 -j ACCEPT
ExecStart=/usr/sbin/iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
ExecStop=/usr/sbin/iptables -t nat -D POSTROUTING -s 10.9.0.0/24 ! -d 10.9.0.0/24 -j SNAT --to 109.**.**.**
ExecStop=/usr/sbin/iptables -D INPUT -p udp --dport 1195 -j ACCEPT
ExecStop=/usr/sbin/iptables -D FORWARD -s 10.9.0.0/24 -j ACCEPT
ExecStop=/usr/sbin/iptables -D FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target

route -n:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.255.255.1    0.0.0.0         UG    0      0        0 ens192
10.9.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun1
10.255.255.1    0.0.0.0         255.255.255.255 UH    0      0        0 ens192
192.168.1.0     10.9.0.2        255.255.255.0   UG    0      0        0 tun1

My ifconfig:

ens192: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 109.**.**.**  netmask 255.255.255.255  broadcast 109.**.**.**
        inet6 fe80::250:56ff:fe38:3071  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:38:30:71  txqueuelen 1000  (Ethernet)
        RX packets 60970  bytes 36346497 (36.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 38831  bytes 5023540 (5.0 MB)
        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 224  bytes 18964 (18.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 224  bytes 18964 (18.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.9.0.1  netmask 255.255.255.0  destination 10.9.0.1
        inet6 fe80::1cc2:31bc:3c20:c922  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 11  bytes 528 (528.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

How do I apply masquerading? I followed this guide: https://www.cyberciti.biz/faq/ubuntu-18-04-lts-set-up-openvpn-server-in-5-minutes/

The configuration has predefined settings. I thought I changed them all but maybe I forgot something?

trendy · December 9, 2021, 12:31pm

iptables-save -c; cat /proc/sys/net/ipv4/ip_forward; ip -4 ru

sinan92 · December 9, 2021, 12:50pm

Gives me the following result:

# Generated by iptables-save v1.8.4 on Thu Dec  9 12:48:29 2021
*filter
:INPUT ACCEPT [5988:942101]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5442:707483]
[32382:5285342] -A INPUT -p udp -m udp --dport 1195 -j ACCEPT
[0:0] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
[27572:3241586] -A FORWARD -s 10.9.0.0/24 -j ACCEPT
COMMIT
# Completed on Thu Dec  9 12:48:29 2021
# Generated by iptables-save v1.8.4 on Thu Dec  9 12:48:29 2021
*nat
:PREROUTING ACCEPT [9284:1004602]
:INPUT ACCEPT [1520:340726]
:OUTPUT ACCEPT [30:2800]
:POSTROUTING ACCEPT [7791:666400]
[0:0] -A PREROUTING -i ens192 -p tcp -m tcp --dport 44158 -j DNAT --to-destination 10.9.0.2:44158
[0:0] -A PREROUTING -i ens192 -p tcp -m tcp --dport 44158 -j DNAT --to-destination 10.9.0.2:44158
[0:0] -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 109.228.40.81
COMMIT
# Completed on Thu Dec  9 12:48:29 2021
1
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

The last POSTROUTING looks wrong. How can I change it? Should be 10.9.0.0 right?

Is the following command correct? (I don't want to mess it up and I'm not linux guru like you guys are)
iptables -A POSTROUTING -s 10.9.0.0/24 ! -d 10.9.0.0/24 -j SNAT --to-source 109.228.40.81

vgaetera · December 9, 2021, 1:07pm

The subnets 10.8.0.0/24 and 10.9.0.0/24 are mixed in the dump.
And zero hits against 10.8.0.0/24 indicates it is the wrong one.

sinan92 · December 9, 2021, 1:14pm

Yes I'm pretty sure now that causes an issue. But I can't find the command to edit that to 10.9.0.0 instead. I'm looking into iptables -R

vgaetera · December 9, 2021, 1:15pm

sudo iptables -t nat -D POSTROUTING \
    -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 109.228.40.81
sudo iptables -t nat -A POSTROUTING \
    -i tun+ -s 10.9.0.0/24 ! -d 10.9.0.0/24 -j MASQUERADE

sinan92 · December 9, 2021, 1:22pm

This solved it! Thank you so much guys finally got it working!

system · December 19, 2021, 1:22pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.