11

I am new to this community and am hopeful that somebody can help me. Please let me know if I haven't posted all required information.

Situation:

  • I have a linux server (raspberry pi, 192.168.1.2) functioning as an OpenVPN client (tun1) to a Paid VPN provider. I do share this VPN connection locally with LAN clients by using the linux server as their default gateway (192.168.1.2). This is working without any issues.

  • On the very same linux server I am running a separate openVPN instance (VPN Server, tun0) to allow WAN clients to connect. This is also working without any issues as long as the VPN Client connection to the Paid VPN provider is not established.

  • My ultimate goal is to share the Paid VPN Connection (tun1) with WAN clients that connect through the separate openVPN server (tun0) instance.

Scheme of my Local Network Setup:

enter image description here

Problem:

  • The openVPN client and the openVPN server instance work fine as long as I don't run them simultaneously. As soon as they openVPN client has a connection to the Paid VPN provider, the WAN clients are unable to connect to the openVPN server.

  • By reviewing the log files I found out that the WAN client handshake fails as soon as the Paid VPN connection is established. I think this is due to the fact that once this Paid VPN connection is established all outgoing internet traffic is routed through the tunnel (tun1) so the client's handshake requests remains unanswered. I do not know how to solve this.

ifconfig

pi@server:~ $ ifconfig -a
eth0      Link encap:Ethernet  HWaddr b8:27:eb:f2:c1:98
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth1      Link encap:Ethernet  HWaddr 58:82:a8:8d:9a:fa
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:203 errors:0 dropped:0 overruns:0 frame:0
          TX packets:165 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:22948 (22.4 KiB)  TX bytes:24938 (24.3 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.77.0.1  P-t-P:10.77.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.130.1.70  P-t-P:10.130.1.69  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

iptables

pi@server:~ $ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:1199

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  10.77.0.0/24         anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Route -n (when tun0/tun1 are not running & not connected)

pi@server:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

Route -n (when tun0 is running & connected)

pi@server:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
10.77.0.0       10.77.0.2       255.255.255.0   UG    0      0        0 tun0
10.77.0.2       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

Route -n (when tun1 is running & connected)

pi@raspi-cyberghost:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.130.0.133    128.0.0.0       UG    0      0        0 tun1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
10.77.0.0       10.77.0.2       255.255.255.0   UG    0      0        0 tun0
10.77.0.2       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.130.0.1      10.130.0.133    255.255.255.255 UGH   0      0        0 tun1
10.130.0.133    0.0.0.0         255.255.255.255 UH    0      0        0 tun1
107.183.241.2   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
128.0.0.0       10.130.0.133    128.0.0.0       UG    0      0        0 tun1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

OpenVPN Server (tun0) error log when trying to connect while OpenVPN client (tun1) is connected

Tue Mar 21 08:06:19 2017 us=593849 172.56.28.50:24844 TLS: Initial packet from [AF_INET]172.56.28.50:24844, sid=d25df6fb 2136a7cc
Tue Mar 21 08:07:19 2017 us=128339 172.56.28.50:24844 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 21 08:07:19 2017 us=128603 172.56.28.50:24844 TLS Error: TLS handshake failed
Tue Mar 21 08:07:19 2017 us=129254 172.56.28.50:24844 SIGUSR1[soft,tls-error] received, client-instance restarting
Improve this question
1
  • You can enable duplicate cn option on openvpn /etc/openvpn/server.conf that allowed more openvpn client.
    – supriady
    Mar 21, 2017 at 17:47

1 Answer 1

Reset to default
5

Found my solution. The problem is that it's necessary to build two routing tables: one handles incoming traffic to the Pi (and its corresponding replies), and the other handles outgoing traffic from the Pi (and its replies).

This second routing table solved it for me:

ip rule add from 192.168.1.2 lookup 10           # Pi server
ip route add default via 192.168.1.1 table 10    # LAN router
Improve this answer
4
  • Thanks so much for this! We found this after wasting ~5 hours on this problem!
    – mikestreety
    Dec 19, 2017 at 14:55
  • Can you give an example of the command based on your infra ? I have the same problem, and for now this solution doesn't work. perhaps its due to my misundertsand of <your-server-ip> & <your-router-ip>. Thanks by advance
    – logisima
    Dec 27, 2017 at 18:12
  • ip rule add from 192.168.1.2 lookup 10
    – khofm
    Dec 28, 2017 at 21:00
  • ip route add default via 192.168.1.1 table 10
    – khofm
    Dec 28, 2017 at 21:00

You must log in to answer this question.

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