OpenVPN Client Connection through existing OpenVPN Router Connection causes DISCONNECT

[Viktor Jaep]

Regardless of what's happening with the laptop's AirVPN connection as far as the router is concerned it's just regular (UDP?) network traffic. It makes no difference that your laptop is using it for VPN, it could be being used for anything. So I can't see why (only) that would cause your router's VPN to break. The first step would be to examine the router's syslog to determine the reason why the VPN terminated.

P.S. Yes, MTU is the most obvious thing to look at (e.g. tun-mtu 1420). You could also try switching the VPN's to TCP instead of UDP. That should be more resilient albeit at the cost of performance.

Alrighty... I made some MTU changes to the NordVPN side of the house, and will see if I can break the router VPN by making a connection on my laptop with an even lower MTU this evening. If I can, I'll see if I can share some syslogs to see if it'll give us a cause. I really appreciate both your suggestions, @ColinTaylor and @RMerlin

 

[Viktor Jaep]

Or it's the NSA shutting it down for bouncing through too many VPNs at once.
[Removing tinfoil hat]

Hats off to the NSA if they were able to accomplish that! <no pun intended>

 

[Viktor Jaep]

Keep in mind that when encapsulating a packet within a packet, the max packet size of the inner one will have to be smaller. So, the inner tunnel might need to have a smaller MTU configured for it.

So the question/thought I have here is if something violates this packet size encapsulation, would that cause OpenVPN to just give up, quit and cause a disconnect? You would think that it would just try to reject that traffic, no?

Even on the WAN side... if the MTU is set for 1500, and I'm using, say 4096, on my laptop's VPN side... what is the expected behavior?

 

[RMerlin]

So the question/thought I have here is if something violates this packet size encapsulation, would that cause OpenVPN to just give up, quit and cause a disconnect? You would think that it would just try to reject that traffic, no?

An incorrectly configured MTU can cause issues with a tunnel. So if any connection relies on that tunnel (such as a second tunnel), then that second connection will also experience issues.

It's certainly worth investigating, tho personally I'd say you need to just simplify things. Running a VPN within a VPN is less than ideal.

 

[Viktor Jaep]

So interestingly enough... The mystery becomes even stranger. (Router/WAN MTU=1500, Router VPN Slot MTU = 1420, Laptop VPN Client MTU = 1320)

1. The connection will succeed just fine without dropping the Router VPN connection for the 4x that I tried this.
2. However, every time the Laptop VPN client disconnects and issues its SIGTERM to the VPN client, VPNMON wants to kill the Router VPN connection, because it can no longer ping 8.8.8.8. This happened every time. I killed VPNMON to look at this behavior further... I can still browse the internet. Just seems I can no longer ping through the main Router VPN tunnel:

From the router tried 8.8.8.8 and 9.9.9.9:

ViktorJp@GT-AX6000-3C88:/tmp/home/root# ping -I tun11 -q -c 3 -W 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

ViktorJp@GT-AX6000-3C88:/tmp/home/root# ping -I tun11 -q -c 3 -W 2 9.9.9.9
PING 9.9.9.9 (9.9.9.9): 56 data bytes

--- 9.9.9.9 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Can't ping from my Windows laptop on the LAN for the Router's VPN Tunnel either.

But then as soon as the VPN tunnel is reset on the router, voila... everything works again.

ViktorJp@GT-AX6000-3C88:/tmp/home/root# ping -I tun11 -q -c 3 -W 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 17.525/18.482/19.179 ms

 

[ZebMcKayhan]

I killed VPNMON to look at this behavior further... I can still browse the internet. Just seems I can no longer ping through the main Router VPN tunnel:

This behaviour is consistent with rp_filter being set to strict. Open vpn seems to force disable all intrrface rp_filter when connecting. Could be worth a check?

cat /proc/sys/net/ipv4/conf/tun11/rp_filter

 

[Viktor Jaep]

This behaviour is consistent with rp_filter being set to strict. Open vpn seems to force disable all intrrface rp_filter when connecting. Could be worth a check?

cat /proc/sys/net/ipv4/conf/tun11/rp_filter

This is the result... I looked at it before and after the Router VPN tunnel gets into its loss-of-ping state... no change.

ViktorJp@GT-AX6000-3C88:/tmp/home/root# cat /proc/sys/net/ipv4/conf/tun11/rp_filter
0

 

[ZebMcKayhan]

This is the result... I looked at it before and after the Router VPN tunnel gets into its loss-of-ping state... no change.

ViktorJp@GT-AX6000-3C88:/tmp/home/root# cat /proc/sys/net/ipv4/conf/tun11/rp_filter
0

Still disabled so it's not that then.

Well, if all interface ips, routes and rules are still the same, the issue is either on lower level or on "the other side".