OpenVPN Server/Client and Dual-WAN

[vertigo888]

Hi,

When in Dual-WAN Load balancing mode, my AC5300 OpenVPN server allows clients to connect. However, my clients have no internet access.

I know the issue is that it's the Dual-WAN because when this is switched off, OpenVPN server and clients function as planned.

Please help. Thanks in advance

 

[Martineau]

Hi,

When in Dual-WAN Load balancing mode, my AC5300 OpenVPN server allows clients to connect. However, my clients have no internet access.

I know the issue is that it's the Dual-WAN because when this is switched off, OpenVPN server and clients function as planned.

FYI: There is no need (immediately after posting to the forum) to PM me with the same question - I am fully able to see posts in the forum...….meaning, if I feel that I can provide useful technical feedback (and I have the necessary interest/motivation) I will respond.

OK, it's been a while since I used Dual-WAN, and at the moment I do not have access to a Dual-WAN configured router, but hopefully I can recall the usual configuration.

So usually, in single WAN mode, the OpenVPN server subnets appear in the 'main' (254) routing table with their originating interface:

e.g.

ip route show table 254 | grep tun2

10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1

So for Dual-WAN Load-Balancing mode, it uses two routing tables

wan0 (100) - Primary WAN
wan1 (200) - Secondary WAN​

so I would first check if both tables contain the appropriate VPN Server entries, otherwise more in-depth analysis of the existing 'OVPN/Balance' chains will be required.

 

[vertigo888]

Hi - apologies for the double messaging. You were right, tun entries are missing from both table 100 and 200 but are in 254 or main.

Any ideas as to how to fix the chain? Should i put something in nat-start to copy from main to table 100 and 200?

 

[Martineau]

Hi - apologies for the double messaging. You were right, tun entries are missing from both table 100 and 200 but are in 254 or main.

Any ideas as to how to fix the chain? Should i put something in nat-start to copy from main to table 100 and 200?

nat-start should be fine.

Alternatively, if it was my environment, rather than consider nat-start/wan-event etc. I might opt for exploiting OpenVPN's Server '--client-connect' event.

i.e. until the very first client physically connects, you wouldn't need to care if the Dual-WAN routing tables 100/200 are correctly populated, so unsolicited WAN/firewall restarts can safely be ignored.

e.g. Add the directive in the appropriate VPN Server Customisation GUI....say

client-connect /jffs/scripts/VPNClientConnect.sh

So now 'VPNClientConnect.sh' simply needs to check if the Dual-WAN routing tables contain the appropriate entries, and if not add them.

Obviously I would need to test the scenario where there are potentially several already connected VPN Server clients, and if it is possible that the Dual-WAN tables 100/200 could be unexpectedly trashed/rebuilt.

 

[vertigo888]

Thanks, so adding the below entries manually seems to work after an nvram commit.

So I'd put this in nat-start at the end? or customisation GUI via a script?
ip route add 10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1 table 100
ip route add 10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1 table 200

Also, once I add these, how would I direct traffic on tun21 to only go via primary or secondary WAN?

 

[Martineau]

Thanks, so adding the below entries manually seems to work after an nvram commit.

Err... not sure of the relevance of the 'nvram commit' ?

how would I direct traffic on tun21 to only go via primary or secondary WAN?

It is more flexible to route using the VPN Server IP pool rather than the actual tun21 interface, i.e. you could also selectively route specific VPN Server connected clients.

Hopefully IP-based RPDB rule(s) should work, so give the commands a try.

e.g. Route ALL VPN Server 1 clients via wan0 (Primary WAN)

ip rule del prio 15 2>/dev/null

ip rule add from "$(nvram get vpn_server1_sn)/24" table wan0 prio 15

ip route flush cache

 

[vertigo888]

So I took what you said and added the below to VPNClientConnect.sh, made it executable and added it to the VPN Server GUI. Works like a charm! Thank you very much

#!/bin/sh

$tun21_table=$(ip route show table 100 | grep -Ev ^default | grep -E tun21)
if [ -z "$tun21_table" ];then

    ip route add "$(nvram get vpn_server1_sn)/24" dev tun21 proto kernel scope link src "$(nvram get vpn_server1_sn | cut -d'.' -f1-3).1" table 100

    ip route add "$(nvram get vpn_server1_sn)/24" dev tun21 proto kernel scope link src "$(nvram get vpn_server1_sn | cut -d'.' -f1-3).1" table 200

    ip rule del prio 15 2>/dev/null

    ip rule add from "$(nvram get vpn_server1_sn)/24" table wan0 prio 15

    ip route flush cache

fi

However, I have VPN clients on the router to a third party VPN provider and the interface tun11 is also missing from table 100 and table 200. For some reason, adding the below to nat-start does not work, neither does adding it to wan-event. I did try adding "script-security 2", together with "route-up /jffs/scripts/scriptname.sh" to the OpenVPN Client GUI but to no avail either. Adding manually via SSH terminal does work though.

I would also like to ensure that the VPN client goes through either wan0 or wan1.

Any ideas to the above? Cheers so far. Really appreciated.

Any ideas?

$tun11_table=$(ip route show table 100 | grep -Ev ^default | grep -E tun11)
if [ -z "$tun11_table" ];then

    ip route add 10.2.10.0/24 dev tun11  proto kernel  scope link  src 10.2.10.178 table 100

    ip route add 10.2.10.0/24 dev tun11  proto kernel  scope link  src 10.2.10.178 table 200

fi

 

[Martineau]

#!/bin/sh

$tun21_table=$(ip route show table 100 | grep -Ev ^default | grep -E tun21)
if [ -z "$tun21_table" ];then

FYI, given the syntax error(s), the code clause above will always add the rules for every client connection, as the variable is never actually created/set to something other than NULL.

Variable assignment statements cannot start with '$'

i.e. you meant to code

tun21_table=$(ip route show table 100 | grep -Ev ^default | grep -E tun21)
if [ -z "$tun21_table" ];then

Also ensure the following modified clause is only executed if the RPDB rule doesn't exist.

if [ -z "$(ip rule | grep -E "^15:")" ];then
   #ip rule del prio 15 2>/dev/null
   ip rule add from "$(nvram get vpn_server1_sn)/24" table wan0 prio 15
   ip route flush cache
fi

NOTE: To prevent duplicates, the original code (stolen from vpnclientX-route-up) deletes the routing RPDB rule, which could impact active connections in the brief interval between deleting the rule and re-adding it.

I would also like to ensure that the VPN client goes through either wan0 or wan1.

If you have a DDNS (usually the case for WAN0) or static IP(s), then it's very simple to add one-line to the VPN Client Configuration GUI to bind the VPN client to a specific WAN,

local ddns_name

or

local xxx.xxx.xxx.xxx

alternatively you may need a script - see [Solved] Dual Wan with 1 OpenVpn Client and ability to choose from which to WAN to go out, although I don't know if the script I posted is still appropriate.

 

[vertigo888]

Thanks for the above, only just got around to this.

This works but my VPN clients seem to bypass the tunnel completely. I have VPN client 2 on my dual WAN that connects correctly with strict policy access enabled and supposedly internet traffic being passed through the tunnel. However, when I check on my public IP via the the VPN clients on my LAN referred to by the strict policy access, the IP is one of my WAN. I know this policy may be table related but don't know how to fix it.

I was trying to have VPN client 2 go through wan1 and all traffic from 192.168.1.7 go through this tunnel via strict policy.

Any ideas?

 

[Martineau]

Thanks for the above, only just got around to this.

This works but my VPN clients seem to bypass the tunnel completely. I have VPN client 2 on my dual WAN that connects correctly with strict policy access enabled and supposedly internet traffic being passed through the tunnel. However, when I check on my public IP via the the VPN clients on my LAN referred to by the strict policy access, the IP is one of my WAN. I know this policy may be table related but don't know how to fix it.

I was trying to have VPN client 2 go through wan1 and all traffic from 192.168.1.7 go through this tunnel via strict policy.

Any ideas?

If you follow post #8 you bind VPN Client 2 to wan1 using the appropriate 'local xxx.xxx.xxx.xxx' GUI directive

For Dual-WAN, the RPDB rules created by the Selective Routing GUI are now too low a priority, as the higher priority Dual-WAN Load-Balancing (LB) RPDB rules take precedence.

see Firmware 384.4, Dual-WAN VPN rules not working

If modifying 'vpnrouting.sh' is too difficult, then you could try the following:

List the current GUI generated RPDB rules (that are valid for Single-WAN environments):

ip rule

and use a one-line command to generate the commands (that should be executed when the VPN Client is started) to replicate the existing Selective Routing rules with a higher priority for a Dual-WAN environment:

e.g. for VPN Client 2

VPN_ID=2;ip rule | grep "10$((VPN_ID*2-1))" | tr '\t' ' ' | awk -v x="${VPN_ID}" '{ $1=""; print "ip rule add"$0" prio "x"5"}'

So simply copy'n'paste the resulting commands into the SSH session to test.

e.g. Hopefully the one-line command above produces a line like this:

ip rule add from 192.168.1.7 lookup ovpnc2 prio 25

If it works to your satisfaction, a simple copy'n'paste into 'vpnclientX-route-up' and the corresponding delete in 'vpnclientX-down' will make it persistent over a bounce of the VPN Client.

 

[SomeWhereOverTheRainBow]

FYI: There is no need (immediately after posting to the forum) to PM me with the same question - I am fully able to see posts in the forum...….meaning, if I feel that I can provide useful technical feedback (and I have the necessary interest/motivation) I will respond.

OK, it's been a while since I used Dual-WAN, and at the moment I do not have access to a Dual-WAN configured router, but hopefully I can recall the usual configuration.

So usually, in single WAN mode, the OpenVPN server subnets appear in the 'main' (254) routing table with their originating interface:

e.g.

ip route show table 254 | grep tun2

10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1

So for Dual-WAN Load-Balancing mode, it uses two routing tables

wan0 (100) - Primary WAN
wan1 (200) - Secondary WAN​

so I would first check if both tables contain the appropriate VPN Server entries, otherwise more in-depth analysis of the existing 'OVPN/Balance' chains will be required.

nat-start should be fine.

Alternatively, if it was my environment, rather than consider nat-start/wan-event etc. I might opt for exploiting OpenVPN's Server '--client-connect' event.

i.e. until the very first client physically connects, you wouldn't need to care if the Dual-WAN routing tables 100/200 are correctly populated, so unsolicited WAN/firewall restarts can safely be ignored.

e.g. Add the directive in the appropriate VPN Server Customisation GUI....say

client-connect /jffs/scripts/VPNClientConnect.sh

So now 'VPNClientConnect.sh' simply needs to check if the Dual-WAN routing tables contain the appropriate entries, and if not add them.

Obviously I would need to test the scenario where there are potentially several already connected VPN Server clients, and if it is possible that the Dual-WAN tables 100/200 could be unexpectedly trashed/rebuilt.

you are brilliant, you just saved me a bunch of time by following your logic with my dual wan setup, do you have a donation's link or a Go-Fund- @Martineau so your loyal patronage can pay tribute?

 

[vertigo888]

If you follow post #8 you bind VPN Client 2 to wan1 using the appropriate 'local xxx.xxx.xxx.xxx' GUI directive

For Dual-WAN, the RPDB rules created by the Selective Routing GUI are now too low a priority, as the higher priority Dual-WAN Load-Balancing (LB) RPDB rules take precedence.

see Firmware 384.4, Dual-WAN VPN rules not working

If modifying 'vpnrouting.sh' is too difficult, then you could try the following:

List the current GUI generated RPDB rules (that are valid for Single-WAN environments):

ip rule

and use a one-line command to generate the commands (that should be executed when the VPN Client is started) to replicate the existing Selective Routing rules with a higher priority for a Dual-WAN environment:

e.g. for VPN Client 2

VPN_ID=2;ip rule | grep "10$((VPN_ID*2-1))" | tr '\t' ' ' | awk -v x="${VPN_ID}" '{ $1=""; print "ip rule add"$0" prio "x"5"}'

So simply copy'n'paste the resulting commands into the SSH session to test.

e.g. Hopefully the one-line command above produces a line like this:

ip rule add from 192.168.1.7 lookup ovpnc2 prio 25

If it works to your satisfaction, a simple copy'n'paste into 'vpnclientX-route-up' and the corresponding delete in 'vpnclientX-down' will make it persistent over a bounce of the VPN Client.

So all in all, really appreciate the help. I've solved my problem. For others reading this, in the end for my Dual WAN setup, I did the following:

1. VPN Server to go through a certain WAN

Added "client-connect /jffs/scripts/vpnclientconnect.sh" (with correct execution bit) to my VPN Server Configuration

vpnclientconnect.sh contains the following for my VPN server to go through wan0:

#!/bin/sh
tun21_table100=$(ip route show table 100 | grep -Ev ^default | grep -E tun21)
if [ -z "$tun21_table100" ];then

ip route add "$(nvram get vpn_server1_sn)/24" dev tun21 proto kernel scope link src "$(nvram get vpn_server1_sn | cut -d'.' -f1-3).1" table 100

    ip route flush cache

fi

tun21_table200=$(ip route show table 200 | grep -Ev ^default | grep -E tun21)
if [ -z "$tun21_table200" ];then

    ip route add "$(nvram get vpn_server1_sn)/24" dev tun21 proto kernel scope link src "$(nvram get vpn_server1_sn | cut -d'.' -f1-3).1" table 200

    ip route flush cache

fi

if [ -z "$(ip rule | grep -E "^15:" | grep -E wan0)" ];then
    #ip rule del prio 15 2>/dev/null

    ip rule add from "$(nvram get vpn_server1_sn)/24" table wan0 prio 15

    ip route flush cache

fi

2.VPN Client to go through a certain WAN:

I used the below link as suggested https://www.snbforums.com/threads/s...-to-choose-from-which-to-wan-to-go-out.38146/

I added local wan0 (or wan1) as required but if you have more than 2 clients using the same script in their respective postconf files, it has a bind issue. My workaround is to add "port 1195" or a different port number than an existing VPN client/server is using locally and then use a port trigger to the remote port specified by the VPN client. No more bind issues after this!

And then to add the respective client IP rule with priority I installed x3mrouting addon and placed this scripts in /jffs/scripts/x3mrouting

"vpnclientX-route-up"

I coded this

#!/bin/sh

VPN_ID=1 #ID of the VPN Client
ip rule | grep "10$((VPN_ID*2-1))" | tr '\t' ' ' | awk -v x="${VPN_ID}" '{ $1=""; print $0" prio "x"5"}' \
  | while read RULE ; do
      ip rule add $RULE
 done

"vpnclientX-down"

I coded this

#!/bin/sh

VPN_ID=1 #ID of the VPN Client
ip rule | grep "10$((VPN_ID*2-1))" | tr '\t' ' ' | awk -v x="${VPN_ID}" '{ $1=""; print $0" prio "x"5"}' \
  | while read RULE ; do
      ip rule del $RULE
 done

This way I don't have to manually hard code any clients I set. They are added and removed through the bounce automatically