What's new

Open VPN Kill Switch Upon VPN Reconnect

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Atreides Modi

Occasional Visitor
Assumption: Kill Switch will block traffic until such time as OpenVPN connection is re-established.

Situation: Have the following configuration for OpenVPN Client on RT_AC3100 with 384.13_0:
  • Connection Retry attempts set to "-1"
  • Force Internet traffic through tunnel set to "Policy Rules"
  • Block routed clients if tunnel goes down set to "Yes"
  • Internal FireTV device added with destination 0.0.0.0 and iface to "VPN"
  • Custom configuration set to
    • resolv-retry infinite
    • persist-remote-ip
    • verify-x509-name us2.vyprvpn.com name
    • keepalive 10 60
    • tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
VPN Client runs like a champ. Until, it appears, I have an ISP disconnect and/or remote VPN server disconnect, which drops the connection and triggers the kill switch for FireTV.

When the router re-establishes internet connection, the OpenVPN client does properly reconnect as evidenced by VPN Status tab. So far so good. EXCEPT; the FireTV remains blocked, presumably by the kill switch (e.g. Ethernet connected, but no Internet connection).

Restarting OpenVPN Client immediately reinstates the FireTV internet connection through tunnel. Ideas?
 
Assumption: Kill Switch will block traffic until such time as OpenVPN connection is re-established.

Situation: Have the following configuration for OpenVPN Client on RT_AC3100 with 384.13_0:
  • Connection Retry attempts set to "-1"
  • Force Internet traffic through tunnel set to "Policy Rules"
  • Block routed clients if tunnel goes down set to "Yes"
  • Internal FireTV device added with destination 0.0.0.0 and iface to "VPN"
  • Custom configuration set to
    • resolv-retry infinite
    • persist-remote-ip
    • verify-x509-name us2.vyprvpn.com name
    • keepalive 10 60
    • tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
VPN Client runs like a champ. Until, it appears, I have an ISP disconnect and/or remote VPN server disconnect, which drops the connection and triggers the kill switch for FireTV.

When the router re-establishes internet connection, the OpenVPN client does properly reconnect as evidenced by VPN Status tab. So far so good. EXCEPT; the FireTV remains blocked, presumably by the kill switch (e.g. Ethernet connected, but no Internet connection).

Restarting OpenVPN Client immediately reinstates the FireTV internet connection through tunnel. Ideas?
If the KILL-switch is currently ACTIVE for a VPN Client, then 'prohibit' will appear in the appropriate Selective routing table:
Code:
for i in 1 2 3 4 5;do echo -en "VPN Client $i: ";ip route show table 11$i | grep -E "^default|prohibit";echo;done

ip rule
However, if the KILL-switch is NOT in force for the VPN connection, if the nominated VPN device still cannot seemingly utilise the tunnel, then either DNS is unavailable - particularly likely if 'Accept DNS Configuration=EXCLUSIVE' and/or the tunnel is unable to actually pass data.

In the case of an unexpected WAN restart, a modified nat-start script can easily check if the VPN status is marked as currently UP, and can subsequently explicitly restart the VPN client.

Alternatively, you could deploy a proactive VPN monitoring script e.g. VPN Failover
 
Unrelated to the kill switch issue, have an OpenVPN related question...

Noticing that Adaptive QOS
If the KILL-switch is currently ACTIVE for a VPN Client, then 'prohibit' will appear in the appropriate Selective routing table:
Code:
for i in 1 2 3 4 5;do echo -en "VPN Client $i: ";ip route show table 11$i | grep -E "^default|prohibit";echo;done

ip rule
However, if the KILL-switch is NOT in force for the VPN connection, if the nominated VPN device still cannot seemingly utilise the tunnel, then either DNS is unavailable - particularly likely if 'Accept DNS Configuration=EXCLUSIVE' and/or the tunnel is unable to actually pass data.

In the case of an unexpected WAN restart, a modified nat-start script can easily check if the VPN status is marked as currently UP, and can subsequently explicitly restart the VPN client.

Alternatively, you could deploy a proactive VPN monitoring script e.g. VPN Failover

Thanks for this helpful response. As an FYI, I have "Accept DNS Configure=Disabled". With this advice, I will share my test findings and resolution.
 
Wondering if I even need the "Block routed clients if tunnel goes down" enabled, since setting "Force Internet traffic through tunnel" to Policy (Strict) which appears to block traffic when the connection is down and resumes properly when link is back up. Maybe I am misunderstanding something, but it doesn't appear to exhibit any traffic leakage.
 
Wondering if I even need the "Block routed clients if tunnel goes down" enabled, since setting "Force Internet traffic through tunnel" to Policy (Strict) which appears to block traffic when the connection is down and resumes properly when link is back up. Maybe I am misunderstanding something, but it doesn't appear to exhibit any traffic leakage.
If you enable 'Block routed clients if tunnel goes down', then during the boot process the WAN blocking rule is immediately in effect for the associated Selective Routing VPN Client devices.

So if you never actually start the VPN Client, or manually terminate the VPN Client (either via the GUI or via a 'service stop_vpnclientX' command) then the defined VPN only devices will actually use the WAN.
 
So a little more testing with the above configuration ("Block routed clients if tunnel goes down" disabled and "Force internet traffic through tunnel" set to Policy. When the networked client looses its connection through the tunnel (e.g. curl ifconfig.me), I can still see the tunnel working from the router (e.g. curl ifconfig.me --interface tun11).

Before and after ip route show table 1 returns no results. Unsure what to look at to pin down what's causes the route to break. Not seeing anything in the logs. So where could I look to figure out why with "Block routed clients(...)" disabled and tun11 working that the client would be blocked.

UPDATE - Did a bunch of cleaning / updated / installing (x3mrouting, connmon, scribe) / restarts and so far the connection has remained up. I'll continue to monitor and if things go awry again I will share some more detailed logs / config info. Thanks @Martineau)
 
Last edited:
Okay, I did some log compares of when the tunnel goes down due to keepalive 10 60 issuing a SIGUSR1 versus when it is restart manually triggered producing a SIGTERM. The only difference I see is in where the below ERROR BLOCK occurs:

ERROR BLOCK
Preserving previous TUN/TAP instance: tun11
NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
vpnrouting.sh tun11 1500 1553 10.2.2.127 255.255.255.0 init
Configuring policy rules for client 1
/usr/sbin/ip route del X.X.X.X/32
/usr/sbin/ip route del 0.0.0.0/1
ERROR: Linux route delete command failed: external program exited with error status: 2
/usr/sbin/ip route del 128.0.0.0/1
ERROR: Linux route delete command failed: external program exited with error status: 2
Closing TUN/TAP interface
/usr/sbin/ip addr del dev tun11 10.2.2.127/24
updown.sh tun11 1500 1553 10.2.2.127 255.255.255.0 init

COMMON (1) TO SIGUSR1 and SIGTERM
NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
TCP/UDP: Preserving recently used remote address: [AF_INET]X.X.X.X:443
Socket Buffers: R=[122880->122880] S=[122880->122880]
UDP link local: (not bound)
UDP link remote: [AF_INET]X.X.X.X:443
TLS: Initial packet from [AF_INET]X.X.X.X:443, sid=6b7580ff 14412e6b
WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
VERIFY OK: depth=1, C=KY, ST=PLACE, L=PLACE, O=VPN, CN=VPN CA, emailAddress=admin@VPN.com
VERIFY X509NAME OK: C=KY, ST=PLACE, L=PLACE, O=VPN, CN=us2.vyprvpn.com, emailAddress=admin@VPN.com
VERIFY OK: depth=0, C=KY, ST=PLACE, L=PLACE, O=VPN, CN=us2.vyprvpn.com, emailAddress=admin@VPN.com
Control Channel: TLSv1.2, cipher SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
[us2.vyprvpn.com] Peer Connection Initiated with [AF_INET]X.X.X.X:443
SENT CONTROL [us2.vyprvpn.com]: 'PUSH_REQUEST' (status=1)
PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.2.2.1,explicit-exit-notify 5,rcvbuf 524288,route-gateway 10.2.2.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.2.2.107 255.255.255.0,peer-id 9,cipher AES-256-GCM'
OPTIONS IMPORT: timers and/or timeouts modified
OPTIONS IMPORT: explicit notify parm(s) modified
OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Socket Buffers: R=[122880->245760] S=[122880->122880]
OPTIONS IMPORT: --ifconfig/up options modified
OPTIONS IMPORT: route options modified
OPTIONS IMPORT: route-related options modified
OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
OPTIONS IMPORT: peer-id set
OPTIONS IMPORT: adjusting link_mtu to 1625
OPTIONS IMPORT: data channel crypto options modified
Data Channel: using negotiated cipher 'AES-256-GCM'
Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

COMMON (2) TO SIGUSR1 and SIGTERM
TUN/TAP device tun11 opened
TUN/TAP TX queue length set to 1000
/usr/sbin/ip link set dev tun11 up mtu 1500
/usr/sbin/ip addr add dev tun11 10.2.2.4/24 broadcast 10.2.2.255
updown.sh tun11 1500 1553 10.2.2.4 255.255.255.0 init
/usr/sbin/ip route add X.X.X.X/32 via 192.168.100.1
/usr/sbin/ip route add 0.0.0.0/1 via 10.2.2.1
/usr/sbin/ip route add 128.0.0.0/1 via 10.2.2.1
Configuring policy rules for client 1
ovpn-client1[4205]: Initialization Sequence Completed
The SIGUSR1 event sequence is COMMON (1) -> ERROR BLOCK -> COMMON (2) and the SIGTERM event sequence is ERROR BLOCK -> restart of openvpn -> COMMON (1) -> COMMON (2). Hope this makes sense. Note that public IP has been obscured with X.X.X.X.

Here's the route:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.100.1 * 255.255.255.255 UH 0 0 0 eth0
X.X.X.X 192.168.100.1 255.255.255.255 UGH 0 0 0 eth0
192.168.100.0 * 255.255.255.0 U 0 0 0 eth0
10.2.2.0 * 255.255.255.0 U 0 0 0 tun11
192.168.1.0 * 255.255.255.0 U 0 0 0 br0
192.168.0.0 * 255.255.255.0 U 0 0 0 tun21
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 192.168.100.1 0.0.0.0 UG 0 0 0 eth0
 
Last edited:
On closer examination, I think this is key to the SIGUSR1 failure:
Preserving previous TUN/TAP instance: tun11
NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
vpnrouting.sh tun11 1500 1553 10.2.2.127 255.255.255.0 init

Though later on there occurs:
Closing TUN/TAP interface

The SIGTERM sequence is followed by
SIGTERM[soft,exit-with-notification] received, process exiting
OpenVPN 2.4.7 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 31 2019
library versions: OpenSSL 1.1.1c 28 May 2019, LZO 2.08

Seems closing the interface doesn't achieve reopening the TUN/TAP device objective which the restart of OpenVPN achieves... Guessing one of the client settings is tied to this, perhaps one of the persist- directives force having to restart OpenVPN? Is there a way (without new script installs) to force a SIGTERM wherever SIGUSR1 occurs?
resolv-retry infinite
keepalive 10 60
nobind
persist-key
persist-tun
persist-remote-ip
verify-x509-name us2.vyprvpn.com name
verb 3
auth SHA256
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
 
Last edited:
After much analysis, which is complicated by fact that the timing of failure was not easy to time (random), I identified that SIGUSR1 process, the following route is lost / not-recreated:

iptables --line -t nat -nvL
Chain POSTROUTING (policy ACCEPT 95 packets, 7342 bytes)
num pkts bytes target prot opt in out source destination
1 4 240 MASQUERADE all -- * tun11 192.168.1.0/24 0.0.0.0/0

All other route views are identical before and after:
iptables -nvL PREROUTING -t nat --line
iptables -nvL PREROUTING -t mangle --line
ip rule
ip route show table ovpnc1
ip route show table main

Thoughts?
 
Update Sep 6 2019 - Things have been working, though I unfortunately am unsure why / what root cause was. So, won't consider it solved until I've got a week of uptime without failure.

Update Sep 10 2019 - Nope - it has been more resilient, but it failed this morning with same situation - the MASQUERADE route for tun11 gets dropped. Back to the drawing board.
num pkts bytes target prot opt in out source destination
1 41 2483 MASQUERADE all -- * tun11 192.168.1.0/24 0.0.0.0/0
For now, since this seems like a bandaid to a root cause I've yet to find, I added the below to my /jffs/scripts/nat-start script:
iptables -t nat -A POSTROUTING -o tun11 -s 192.168.1.0/24 -j MASQUERADE
 
Last edited:

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top