VPN Director - 2 VPN Clients and Killswitch (3004.388.8_2)

[Skillz]

Hi,

I've just configured 2 OVPN clients, both using VPN Director rules with Killswitch enabled.
OVPN1 has DNS config set to exclusive and OVPN has DNS config set to disabled.

The idea is to have my NAS route through OVPN1, then all other clients through OVPN2, unless I route clients specifically through the WAN.

The Asuswrt-Merlin VPN Director wiki page states the following:

Keep in mind that the killswitch will affect how lower priority clients work. If a higher priority client triggers its killswitch, then no traffic will go through the lower priority clients. You will generally want your lowest priority client to use the killswitch if you use multiple clients.

With above config, As soon as OVPN1 is disabled, my NAS starts (re)routing through OVPN2, instead of -what I'm expecting- killing the connection.
(If I remove the 'LAN to OVPN' rule, the Killswitch for OVPN1 does work, but I need to have my clients go through OVPN2)

How do I configure 192.168.10.2 to only use OVPN1 and kill the connection when OVPN1 disconnects?

Thank you in advance for reading

 

[eibgrad]

A little too much going on there to know for sure where the problem lies. Dump the following so we can see exactly how its configured internally. That often reveals the culprit.

ifconfig
brctl show
ip route show table main
ip route show table ovpnc1
ip route show table ovpnc2
ip rule
iptables -t mangle -vnL
iptables -t nat -vnL
iptables -vnL
cat /tmp/etc/openvpn/client1/config.ovpn
cat /tmp/etc/openvpn/client2/config.ovpn
cat /jffs/openvpn/vpndirector_rulelist
cat /tmp/etc/dnsmasq.conf

Note, do this *after* you've disabled the OpenVPN client so we see the state of the router at the point of failure. Of course, you can mask your public IP, just do so in a way that is obvious and consistent. Do NOT mask any private IPs.

 

[Skillz]

Whats the best way to dump the files? Attach them as .txt files?

(it will be a while (12+ hours) before I respond after this post)

 

[eibgrad]

Let me make it a little easier for you.

Use ssh to access the router and copy/paste the following (in toto) into the terminal window.

while read cmd; do echo ">>> $cmd"; $cmd; echo; done << EOF &>/tmp/dump.txt
ifconfig
brctl show
ip route show table main
ip route show table ovpnc1
ip route show table ovpnc2
ip rule
iptables -t mangle -vnL
iptables -t nat -vnL
iptables -vnL
cat /tmp/etc/openvpn/client1/config.ovpn
cat /tmp/etc/openvpn/client2/config.ovpn
cat /jffs/openvpn/vpndirector_rulelist
cat /tmp/etc/dnsmasq.conf
EOF
:

It will execute and dump the output from those commands to a file called /tmp/dump.txt. You can verify it worked by browsing the output file.

less /tmp/dump.txt

(use home/page-up/page-down/end to review, q to exit)

You can then use scp (Linux) or WinSCP to copy the file to your PC, remove your public IP, and either attach it to a followup post, or perhaps post it to PasteBin.

scp admin@192.168.1.1:/tmp/dump.txt .

 

[Skillz]

Ok here's the info you requested.

My AX86U_Pro is behind a modem that I can't put into bridge mode, so that explains the 192.168.100.2 WAN address (I actually forgot about that).

Pastebin Dump.txt

(there's no ovpn1 info, because that connection was turned off)

 

[eibgrad]

I can see why it's NOT working as expected. But the issue gets a bit complicated, so bear with me.

Prior to 3004.388.8, the kill switch was NOT persistent. After purposely disabling the OpenVPN client, the kill switch would be deactivated. If, however, the OpenVPN client process died of its own accord for some reason, and the kill switch was enabled, the router would insert a "prohibit default" route into that OpenVPN client's routing table (e.g., ovpnc1, in your case) to deny access to the internet. And that OpenVPN client's routing table necessarily remained in-place.

That has all changed according to the 3004.388.8 changelog. Now the kill switch is persistent, even if you disable the OpenVPN client. But there seems to be a difference in how the priority of a kill switch is handled as well, which explains the behavior you're seeing. It's described more precisely by @RMerlin in response to my own (apprarent mis-) understanding of how the kill switch now operates.

https://www.snbforums.com/threads/asuswrt-merlin-3004-388-8_2-is-now-available.91069/post-919044 (see his response specifically to me in that post)

VPN Director Assistance Request

Hello, hoping someone can push in the right direction. I have VPN director setup specifically 2 IP's I route outside to WAN and all rest to VPN. Problem that one of the works, 241 routes outside of VPN and the other .242 does not and routes internally through VPN instead. I have diversion...

www.snbforums.com

If we look at the ip rules from your own dump, we can see the effect of those changes.

0:    from all lookup local
90:    from all to 192.168.11.2 lookup main
90:    from all to 192.168.11.3 lookup main
10010:    from 192.168.10.0/24 to 192.168.10.0/24 lookup main
10011:    from 192.168.10.0/24 to 192.168.11.3 lookup main
10012:    from 192.168.10.10 lookup main
10013:    from 192.168.10.1 lookup main
10410:    from 192.168.11.0/24 lookup ovpnc2
10411:    from 192.168.10.0/24 lookup ovpnc2
12210:    from 192.168.10.2 prohibit
12211:    from 192.168.11.0/24 prohibit
12211:    from 192.168.10.0/24 prohibit
32766:    from all lookup main
32767:    from all lookup default

The first column is the priority (higher numbered = lower priority). While the prohibit rule for 192.168.10.2 is there (#12210), it has *lesser* priority than rule that routes 192.168.10.0/24 through OpenVPN client #2 (#10411)!

That is quite a change from the prior behavior of the kill switch. The prohibit rules have been moved to the ip rules list itself rather than (as before) be managed within the individual OpenVPN client routing tables. It effectively means you can no longer expect a failure or disabling of an OpenVPN client w/ the kill switch enabled to prevent fall-through to another OpenVPN client. All you can guarantee is it won't have access to the WAN, or more precisely, the default gateway associated w/ the main routing table, since the prohibit rules do have higher priority than rule #32766 (main).

IOW, at least according to my understanding of @RMerlin's explanations, it's working as intended.

 

[Skillz]

Thank you for your patience and detailed explaination as it confirms the behavior that I've been seeing.
I hope there will be a 'fix' or workaround for this 'issue/behavior' in the future.

Personally I can work around this by implementing another solution (not on the router), but it would have been great to have it all in one place.

edit: maybe the VPN Director Wiki could be updated describing this new behavior

 

[eibgrad]

What you could do as a workaround on the router is to make the rules for each OpenVPN client mutually exclusive. IOW, rather than 192.168.10.0/24 for OpenVPN client #2, exclude 192.168.10.2. You could do that using a ip range to CIDR calculator.

For example, 192.168.10.3 thru 192.168.10.254 produces ...

192.168.10.3/32
192.168.10.4/30
192.168.10.8/29
192.168.10.16/28
192.168.10.32/27
192.168.10.64/26
192.168.10.128/26
192.168.10.192/27
192.168.10.224/28
192.168.10.240/29
192.168.10.248/30
192.168.10.252/31
192.168.10.254/32

Obviously not very convenient since you now have to add a lot more rules, but it will work.

 

[ZebMcKayhan]

For example, 192.168.10.3 thru 192.168.10.254 produces ...

Sorry to interrupt, but I was just curious about the importance of leaving out .255 (broadcast) ip. Is it really nessisary?

If not there would be fewer rules:

192.168.10.3/32
192.168.10.4/30
192.168.10.8/29
192.168.10.16/28
192.168.10.32/27
192.168.10.64/26
192.168.10.128/25

And ofcource if one were to restrict dhcp range further to say, start with 16 it would be down to 4:

192.168.10.16/28
192.168.10.32/27
192.168.10.64/26
192.168.10.128/25

You could put your nas on .15 and create a special rule for that. All wan clients could be set to static assigned dhcp ip between .2 -.14

This ofcourse assumes adding .255 ip is not a stopper? Otherwise one might add it specifically to wan interface as it would always be local anyway?

 

[Skillz]

I would like to know if @ZebMcKayhan's solution would work, hopefully somebody can chime in.
My knowledge on this matter is to limited.

 

[eibgrad]

Yes, it will work.

All he's suggesting is that you redefine the DHCP range so the NAS is assigned an IP *outside* that range. And now you can specify a minimal number of rules to route the DHCP range over OVPN2 w/o including the NAS.

As I explained, you can continue using 192.168.10.2 through 192.168.10.254 as your DHCP range, w/ the NAS assigned a static IP of 192.168.10.2, and add all the rules I specified. It's not like it isn't going to work. But if you want to save a little typing and increase the efficiency of the process, then limiting the number of rules through the means suggested by @ZebMcKayhan is one way to do it.

One problem in messing w/ the DHCP server's range is that it has the potential of allowing a rogue device to assign itself an IP (192.168.10.3 through 192.168.10.15) to bypass OVPN2. How much of a risk that represents (if at all) is up to you. But it does create at least the opportunity for such mischief.

Personally, I'd be more inclined to follow the good suggestion of leaving out .255, which reduces the rules considerably (it's only the broadcast IP anyway, which can NOT be routed). At that point, messing w/ the DHCP range only saves you another three (3) rules, and at the cost of possibly having some rogue client bypass the VPN.

P.S. If you did the choose to change your DHCP range, nothing says you have to use the entire remaining IP network beyond .15. You could limit the DHCP range from .64 through .127, given you 128 IPs in the pool, and only requiring the following rule.

192.168.10.64/26

 

[ZebMcKayhan]

One problem in messing w/ the DHCP server's range is that it has the potential of allowing a rogue device to assign itself an IP (192.168.10.3 through 192.168.10.15) to bypass OVPN2. How much of a risk that represents (if at all) is up to you. But it does create at least the opportunity for such mischief.

Since the OP have atleast 1 ip set to use WAN it's a risk he/she will have to live with anyway.

But if it's only ever going to be 1 ip to WAN, the OP could select that PC to be 192.168.10.3 via static dhcp and atleast do away with 1 rule:

192.168.10.4/30 #4-7
192.168.10.8/29 #8-15
192.168.10.16/28 #16-31
192.168.10.32/27 #32-63
192.168.10.64/26 #64-127
192.168.10.128/25 #128-255

That would atleast minimize the risks while still preventing overlapping or exception rules.

Ps

You could limit the DHCP range from .64 through .127, given you 128 IPs in the pool,

That's only 64 ip, probably enough for most though.

 

[Skillz]

Thank you both