VPN Kill Switch Doesn't Work Temporarily Immediately After Rebooting

[Magnetron]

I'm running Merlin 386.3_2 on an RT-AC68U. I'm using the OpenVPN client with it set to connect when booted. The kill switch is enabled, and all internet traffic is set to be redirected over the VPN.

I've noticed that traffic is allowed to go over the WAN immediately after rebooting for a short time (about 15 seconds) after the router starts routing and before the VPN finishes connecting. Once the VPN connects, all traffic goes over the VPN. I verified the kill switch works properly if I kill the VPN client over SSH.

It also happens while the VPN is reconnecting after the WAN cable is disconnected and reconnected.

Interestingly, I'm not able to reproduce the problem if I switch from redirecting all traffic to PBR with a rule to send traffic from the entire subnet over the VPN. I would just leave it configured with the PBR rule, but I want to use Diversion and the VPN's DNS server.

I guess I could just configure the firewall to block traffic from going over the WAN, but I'd like to figure out what the problem is. Any ideas?

 

[eibgrad]

I can confirm this same behavior by actually watching the bootup process.

What I do is login via ssh to the router as soon as possible after bootup and run the following command.

watch -tn1 'ip rule; echo; ip route show table ovpnc1'

When using "VPN Director (policy rules)", what you'll see is the following almost immediately.

0:    from all lookup local
10210:    from 192.168.1.0/24 lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

prohibit default

The alternate routing table for OpenVPN client #1 is denying access to the default route, *and* all traffic is being routed to it via the ip rule. That's what you want.

But if you switch to "Yes (all)", you get this instead.

0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default

prohibit default

IOW, there is no ip rule to route *all* traffic to table ovpnc1! Eventually it does get added, but only once the OpenVPN client gets connected. During that time, the WAN is obviously exposed.

0:    from all lookup local
10001:    from all lookup ovpnc1
32766:    from all lookup main
32767:    from all lookup default

104.26.8.66 via 10.182.0.141 dev tun11
10.182.0.1 via 10.182.0.141 dev tun11
193.36.224.85 via 192.168.63.1 dev eth0
104.26.9.66 via 10.182.0.141 dev tun11
10.182.0.141 dev tun11  proto kernel  scope link  src 10.182.0.142
172.67.69.81 via 10.182.0.141 dev tun11
192.168.63.1 dev eth0  proto kernel  scope link
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
192.168.63.0/24 dev eth0  proto kernel  scope link  src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev eth0  metric 1
127.0.0.0/8 dev lo  scope link
default via 10.182.0.141 dev tun11

It would appear to be a timing issue that probably can be corrected by @RMerlin. In the meantime, a firewall rule should be sufficient as a temporary workaround.

Kill switch doesn't work

It seems to me kill switch stopped working for me. I had 386.1.x FW and noticed after router reboot that my OpenVPN client is down and despite I had setting to prevent client access to Internet when VPN is down, client still had access to Internet. I could not make kill switch work so updated to...

www.snbforums.com

 

[eibgrad]

P.S. I can understand why this probably happened. Prior to the VPN Director, it was NOT possible to configure the kill switch for OpenVPN clients that were configured to route ALL over the VPN. You *had* to use routing policy as described by the OP. But w/ the introduction of the VPN Director, that capability became possible (one of many reasons the VPN Director is an improvement in the handling of routing policy). Most likely the choice of VPN Director vs. All changes the path of execution sufficiently to account for this (apparent) bug. As I said, I assume this can be corrected. Stuff like this happens when you make major changes.

 

[Magnetron]

Thanks for the informative reply and script, @eibgrad! I installed the script, and it works great.