Dual VPN client support in 378.54?

[princi]

Judging by the latest github entries, looks like 378.54 might support dual VPN clients out of the box - without having to write scripts....

Fingers crossed - I will be one happy man.

 

[cosmoxl]

I'm not sure that's where it's heading. but, that would be very cool.

 

[RMerlin]

Dual VPN clients has always been supported. There is nothing new there. The fix was specific to policy routing.

Sent from my Nexus 9 using Tapatalk

 

[princi]

Thanks for the reply. I have been meaning to talk to Astrill about supporting dual tunnels in their Merlin Router applet.

The applet supports the 3 radios in the AC3200, so it's the perfect platform for local WAN and two VPN tunnels.

In the meantime, could you recommend a guide and/or script to configure dual VPN tunnels?

BTW, love your phenomenal work!

 

[cosmoxl]

Dual VPN clients has always been supported. There is nothing new there. The fix was specific to policy routing.

Sent from my Nexus 9 using Tapatalk

What will happen if there are conflicts in the two routing policy rules and both tunnels are up? eg policy ruleset of both openvpn clients has same IP going through tunnel.

 

[Martineau]

What will happen if there are conflicts in the two routing policy rules and both tunnels are up? eg policy ruleset of both openvpn clients has same IP going through tunnel.

The first match in the RPDB table will get preference i.e. last VPN Client to be processed/started..however I suspect RMerlin forces VPN Client1 rules to always be processed first!
(P.S. I haven't checked the vpnrouting.sh code, so not sure if the GUI or the script will prevent duplicate entries?)

e.g. my custom RPDB selective routing table shows the following, having just deliberately incorrectly specified the duplicate address 10.88.8.142 (PS3-Bedroom) should use VPN Client2 rather than the expected VPN Client1 via HMA

 ip rule

0:      from all lookup local
1200:   from 10.88.8.142 lookup vpn2
1201:   from 10.88.8.142 lookup hma
30000:  from all fwmark 0x1 lookup hma
30000:  from all fwmark 0x2 lookup vpn2
30001:  from all iif wl1.3 lookup hma
30001:  from all iif wl0.3 lookup hma
32766:  from all lookup main
32767:  from all lookup default

NOTE: Your display will show tables 111 and 112 rather than hma/vpn2 as RMerlin elects not to tag his tables with more meaningful human friendly mnemonics.

 

[RMerlin]

Client 1 rules use a PRIO of 1000 to 1399 (first 200 are for WAN, next ones are for tunnel), and client 2 rules are 1400 to 1799 (same order).

 

[Martineau]

Client 1 rules use a PRIO of 1000 to 1399 (first 200 are for WAN, next ones are for tunnel), and client 2 rules are 1400 to 1799 (same order).

ASUS apparently reserves PRIO 100,200 and 400 for Dual WAN which seemingly limits the number of any higher priority rules to PRIO 1-99? although clearly as they define multiple rules for each PRIO group it appears that having individual PRIO values for your rules isn't necessary? i.e. you could (to match your routing tables identifiers) simply designate PRIO 10000 as WAN, 11100 as VPN1 and 11200 as VPN2 ?

 

[RMerlin]

ASUS apparently reserves PRIO 100,200 and 400 for Dual WAN which seemingly limits the number of any higher priority rules to PRIO 1-99? although clearly as they define multiple rules for each PRIO group it appears that having individual PRIO values for your rules isn't necessary? i.e. you could (to match your routing tables identifiers) simply designate PRIO 10000 as WAN, 11100 as VPN1 and 11200 as VPN2 ?

From what I read in the iproute2 documentation, each rule must have a unique PRIO (even tho the userspace tool seem to allow you to define multiple rules on the same PRIO).

I have no problem in bumping my rules to the 10000 range. However I don't want to change Asus's own, because that would require me to constantly monitor any future changes to ensure they remain in-sync. This would make it too difficult for me to deal with future GPL merges.

 

[Martineau]

From what I read in the iproute2 documentation, each rule must have a unique PRIO (even tho the userspace tool seem to allow you to define multiple rules on the same PRIO).

I have no problem in bumping my rules to the 10000 range. However I don't want to change Asus's own, because that would require me to constantly monitor any future changes to ensure they remain in-sync. This would make it too difficult for me to deal with future GPL merges.

Ahh that old pitfall - "Poor documentation is worse than no documentation at all"
It probably may be prudent to continue to allocate a unique PRIO for each routing rule, unless the kernel uses an efficient hashing algorithm to traverse the RPDB table? - but I guess it must be still ultimately searching sequentially?

Both ASUS and yourself own your proprietary code, so wannabe scripters like myself have to work around your designs, and I know I couldn't perform the tedious GPL merges that you undertake with each of your firmware releases - 6x20mins compile time only to find you missed something can't be fun but is appreciated by the community.

No doubt ASUS have a reason for choosing their PRIO range, and the only advantage I have found in grouping multiple rules with the same PRIO is that I can delete multiple selective routing rules in one go, rather than having to delete them individually.

One final suggestion/request, do you think default fwmark RPDB entries for 111/112 (as shown in my post #6) is a good idea?

This would certainly simplify advanced selective routing based on src/dest/port criteria which currently isn't (yet! ) available via the VPN GUI by taking advantage of your selective routing design.

 

[RMerlin]

Both ASUS and yourself own your proprietary code, so wannabe scripters like myself have to work around your designs, and I know I couldn't perform the tedious GPL merges that you undertake with each of your firmware releases - 6x20mins compile time only to find you missed something can't be fun but is appreciated by the community.

While developing I only compile one single model (either my main, or whichever spare router I use for testing at the time). Once in a while I will git pull all my copies (I keep one separate git clone per model, to make it faster to recompile a specific model, and also to allow building them all in parallel) and run my script to build them all to detect any build issue.

Building all FWs takes about an hour.

One final suggestion/request, do you think default fwmark RPDB entries for 111/112 (as shown in my post #6) is a good idea?

This would certainly simplify advanced selective routing based on src/dest/port criteria which currently isn't (yet! ) available via the VPN GUI by taking advantage of your selective routing design.

I avoid using fwmark because of bwdpi (and never really looked at how it worked in detail since I knew from the beginning it wouldn't work properly), which can flush the PREROUTING chain at any time, breaking any mark-based routing that might be configured. That's why I'm sticking to only RPDB-based rules.


I had a quick look at GPL 6065, and Asus just threw a few curveballs at my plans. They are increasing the number of supported OpenVPN clients to *FIVE*. Sigh. I think I might sit on this one, and stick to two. I have a hard time seeing people needing so many clients, and it seems like a waste of nvram space to have all those nvram settings (even if unset - the variable names themselves will take space). And due to some of my features there, increasing the number beyond 2 is going to require a lot of code rewrites.

Asus managed to increase that amount by moving OpenVPN key/certs to jffs2.

GPL 6065 is going to be a real pain to merge and adapt to my code...

 

[princi]

Great to hear about the future support for 5 VPN clients - I could definately use that. I need it to get around geoblocking - not for security.

 

[RMerlin]

Great to hear about the future support for 5 VPN clients - I could definately use that. I need it to get around geoblocking - not for security.

Don't hold your breath on that one, because at this point, I'm not likely to support those extra clients. A lot of work would be required for me to properly supprot them, due to the more advanced OpenVPN client webui I'm still using.

 

[cosmoxl]

would it be possible to save changes to policy routing (while the client is connected) without forcing the client to go through the connection process again?

 

[RMerlin]

would it be possible to save changes to policy routing (while the client is connected) without forcing the client to go through the connection process again?

Architecture-wise this would be too complicated.