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. Commented Mar 21, 2017 at 17:47

1 Answer 1

Reset to default
6

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! Commented 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 Commented Dec 27, 2017 at 18:12
  • ip rule add from 192.168.1.2 lookup 10 Commented Dec 28, 2017 at 21:00
  • ip route add default via 192.168.1.1 table 10 Commented Dec 28, 2017 at 21:00

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.