OpenVPN Client and Server on same machine - Server doesn't allow connections when client is connected

9,391

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
Share:
9,391

Related videos on Youtube

khofm
Author by

khofm

Updated on September 18, 2022

Comments

  • khofm
    khofm over 1 year

    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
    
  • mikestreety
    mikestreety over 6 years
    Thanks so much for this! We found this after wasting ~5 hours on this problem!
  • logisima
    logisima over 6 years
    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
  • khofm
    khofm over 6 years
    ip rule add from 192.168.1.2 lookup 10
  • khofm
    khofm over 6 years
    ip route add default via 192.168.1.1 table 10