Trouble with Multiple VPN profiles for single source IP / device

[Ratman]

Hi,

I’m new to this forum and fairly new to setting up VPNs. I’ve been searching on the internet and this forum but haven’t come up with anything that was relating to the problem I am facing.

I’m having some trouble with VPN profiles on asus Merlin (389.68_4).
I’ve got client 1 setup to use any worldwide VPN server, client 2 to use US servers, client 3 for European servers (configuration files were uploaded correctly for each client). For each of these client VPN settings I’ve added one single source IP to go via VPN tunnel. The same device (IP source) is added on the other VPN clients as well.

I want to be able to switch off Client 1 (world VPN) and switch on Client 2 (US VPN) so that my device tunnels through US servers instead of any random worldwide server. Therein lies the problem. If I switch off Client 1 and switch on Client 2, my device doesn’t connect to the internet at all. I have to switch off client 2 then switch on client 1 for the internet to start working again.

Any ideas what I’m doing wrong?

Settings for VPN client 1:

Settings for VPN Client 2:

 

[Jack Yaz]

I think the trouble will be caused by the "block routed clients if tunnel goes down". Since it's set on 1, turning 1 off in effect brings the tunnel down, so it blocks internet access. A quick way to check would be to disable that setting on both clients, and see if you can swap between 1 and 2 and maintain internet.

If that proves to be the cause, hopefully someone will be able to help you be able to use that setting, while being able to switch clients with ease.

 

[Martineau]

Hi,

I’m new to this forum and fairly new to setting up VPNs. I’ve been searching on the internet and this forum but haven’t come up with anything that was relating to the problem I am facing.

I’m having some trouble with VPN profiles on asus Merlin (389.68_4).
I’ve got client 1 setup to use any worldwide VPN server, client 2 to use US servers, client 3 for European servers (configuration files were uploaded correctly for each client). For each of these client VPN settings I’ve added one single source IP to go via VPN tunnel. The same device (IP source) is added on the other VPN clients as well.

I want to be able to switch off Client 1 (world VPN) and switch on Client 2 (US VPN) so that my device tunnels through US servers instead of any random worldwide server. Therein lies the problem. If I switch off Client 1 and switch on Client 2, my device doesn’t connect to the internet at all. I have to switch off client 2 then switch on client 1 for the internet to start working again.

Any ideas what I’m doing wrong?

Settings for VPN client 1:
View attachment 10997

Settings for VPN Client 2:
View attachment 10998

The issue is that you (probably) have three entries in the RPDB table
e.g.

ip rule

10101: from xxx.xxx.xxx.xxx lookup ovpnc1
10301: from xxx.xxx.xxx.xxx lookup ovpnc2
10501: from xxx.xxx.xxx.xxx lookup ovpnc3

where xxx.xxx.xxx.xxx (192.168.1.23?) is the device you wish to Selectively route via the current ACTIVE VPN client.

So if VPN Client 1 is DOWN, but VPN Client 3 is UP, then the lowest numbered RPDB rule take precedence, so rule 10101 redirects xxx.xxx.xxx.xxx to routing table ovpnc1, which, as you have specified 'Block routed clients if tunnel goes down=YES' contains directive 'prohibit default' and correctly prevents all outbound internet traffic from that device.

You will need to use the openvpn-event scripts to add an override RPDB rule when the current (i.e. last one started) VPN Client is initialising.

Get @john9527's /jffs/scripts/openvpn-event script: script v2 and create custom script:

/jffs/scripts/vpnclient1-pre-route-up

#!/bin/sh

VPN_ID=${1:4:1}                     # VPN Client

PRIO="9999"                         # Override Policy GUI generated rules

IP_ADDR="xxx.xxx.xxx.xxx"           # <<<==== Change to the device that should be routed via the ACTIVE VPN_Client

RPDB_RULE="from $IP_ADDR table 11$VPN_ID prio $PRIO"

# Check if required RPDB routing rule exists; if not then insert it
if [ -z "$(ip rule 2> /dev/null | grep -oF "$RPDB_RULE")" ];then
   ip rule add $RPDB_RULE
   ip route flush cache
fi

then simply clone this script as-is to /jffs/scripts/vpnclient2-pre-route-up and /jffs/scripts/vpnclient3-pre-route-up

NOTE: When you manually stop the VPN Client connection, you will need to explicitly remove the override RPDB rule using three custom scripts

/jffs/scripts/vpnclientX-pre-route-down.

#!/bin/sh

ip rule del prio 9999 2> /dev/null
ip route flush cache

EDIT: Updated script to always assign static RPDB prio 9999. This will ensure that the xxx.xxx.xxx.xxx device will not be allowed access via the WAN if all three VPN Clients are disconnected based on the 'Block routed clients if tunnel goes down' setting you have enabled.

EDIT 2: Whoops, having given it more thought, you probably don't need to add any custom scripting
Simply keep xxx.xxx.xxx.xxx in the Policy rules for all three VPN Clients, but enable 'Block routed clients if tunnel goes down=YES' for only VPN Client 3.

 

[Ratman]

I think the trouble will be caused by the "block routed clients if tunnel goes down". Since it's set on 1, turning 1 off in effect brings the tunnel down, so it blocks internet access. A quick way to check would be to disable that setting on both clients, and see if you can swap between 1 and 2 and maintain internet.

If that proves to be the cause, hopefully someone will be able to help you be able to use that setting, while being able to switch clients with ease.

Thanks, Jack Yaz. That makes sense. I’ll try that out and see what happens.

 

[Ratman]

The issue is that you probably have three entries in the RPDB table
e.g.

ip rule

10101: from xxx.xxx.xxx.xxx lookup ovpnc1
10301: from xxx.xxx.xxx.xxx lookup ovpnc2
10501: from xxx.xxx.xxx.xxx lookup ovpnc3

where xxx.xxx.xxx.xxx (192.168.1.23?) is the device you wish to Selectively route via the current ACTIVE VPN client.

So if VPN Client 1 is DOWN, but VPN Client 3 is UP, then the lowest numbered RPDB rule take precedence, so rule 10101 prevents access since it redirects xxx.xxx.xxx.xxx to routing table ovpnc1, which, as you have specified 'Block routed clients if tunnel goes down=YES' contains directive 'prohibit default'

You will need to use the openvpn-event scripts to only add the desired RPDB rule when the appropriate VPN Client is UP.
i.e. remove the xxx.xxx.xxx.xxx entry from the Policy rules GUI.

Get @john9527's /jffs/scripts/openvpn-event script: script v2 and create custom script /jffs/scripts/vpnclient1-pre-route-up

#!/bin/sh

VPN_ID=${1:4:1}                     # VPN Client

PRIO="10"$((VPN_ID*2-1))"50"        # Pick 'unused' prio slot???

IP_ADDR="xxx.xxx.xxx.xxx"           # <<<==== Change to the device that should be routed via the ACTIVE VPN_Client

RPDB_RULE="from $IP_ADDR table 11$VPN_ID prio $PRIO"

# Check if required RPDB routing rule exists; if not then insert it
if [ -z "$(ip rule 2> /dev/null | grep -oF "$RPDB_RULE")" ];then
   ip rule add $RPDB_RULE
   ip route flush cache
fi

then simply clone this script as-is to /jffs/scripts//vpnclient2-pre-route-up and /jffs/scripts//vpnclient3-pre-route-up

NOTE: The firmware should remove the RPDB rule automatically when you manually stop the VPN Client connection, but you could explicitly remove the RPDB rule using three custom scripts /jffs/scripts/vpnclientX-pre-route-down.

Wow! You really know your stuff. Thanks for the detailed guide, Martineau. I’ll get the scripts you mentioned and run through the steps. Might take me a while since I’ve never run open vpn event scripts before.

 

[st3v3n]

Ratman, welcome; what's your model or am I more blind than I suspected? I kind of/sort of have an idea, if it's able run three OpenVPN configs, but I'm surely missing something Jack Yaz and Martineau have grasped; I read everything several times, I saw two photos for two configs, but you spoke of three. We've recently discovered our RR-AC3200 under v380.68_4 can run two concurrent (simultaneous) OpenVPN tunnels provided by this build, and likely one or two more, if we back-grade or revert the current build. The router can and does run a third (L2TP) tunnel/config without any problems as well as the server. No clients have WAN access, each of the devices provisioned to both OpenVPN clients accept DNS Exclusive, policy rules/Strict and either drops all devices from that particular tunnel if it disconnects. All tunnels have been for several days, and can direct to any of the gobal/domestic servers our provider offers, without having to turn one or the other off, simply by copying/pasting a server address and saving, if it's necessary. Not that it's anyone's business, why you'd want to shut any of your clients down, just curious. Cheers.

 

[Ratman]

The issue is that you (probably) have three entries in the RPDB table
e.g.

ip rule

10101: from xxx.xxx.xxx.xxx lookup ovpnc1
10301: from xxx.xxx.xxx.xxx lookup ovpnc2
10501: from xxx.xxx.xxx.xxx lookup ovpnc3

where xxx.xxx.xxx.xxx (192.168.1.23?) is the device you wish to Selectively route via the current ACTIVE VPN client.

So if VPN Client 1 is DOWN, but VPN Client 3 is UP, then the lowest numbered RPDB rule take precedence, so rule 10101 redirects xxx.xxx.xxx.xxx to routing table ovpnc1, which, as you have specified 'Block routed clients if tunnel goes down=YES' contains directive 'prohibit default' and correctly prevents all outbound internet traffic from that device.

You will need to use the openvpn-event scripts to add an override RPDB rule when the current (i.e. last one started) VPN Client is initialising.

Get @john9527's /jffs/scripts/openvpn-event script: script v2 and create custom script:

/jffs/scripts/vpnclient1-pre-route-up

#!/bin/sh

VPN_ID=${1:4:1}                     # VPN Client

PRIO="9999"                         # Override Policy GUI generated rules

IP_ADDR="xxx.xxx.xxx.xxx"           # <<<==== Change to the device that should be routed via the ACTIVE VPN_Client

RPDB_RULE="from $IP_ADDR table 11$VPN_ID prio $PRIO"

# Check if required RPDB routing rule exists; if not then insert it
if [ -z "$(ip rule 2> /dev/null | grep -oF "$RPDB_RULE")" ];then
   ip rule add $RPDB_RULE
   ip route flush cache
fi

then simply clone this script as-is to /jffs/scripts/vpnclient2-pre-route-up and /jffs/scripts/vpnclient3-pre-route-up

NOTE: When you manually stop the VPN Client connection, you will need to explicitly remove the override RPDB rule using three custom scripts

/jffs/scripts/vpnclientX-pre-route-down.

#!/bin/sh

ip rule del prio 9999 2> /dev/null
ip route flush cache

EDIT: Updated script to always assign static RPDB prio 9999. This will ensure that the xxx.xxx.xxx.xxx device will not be allowed access via the WAN if all three VPN Clients are disconnected based on the 'Block routed clients if tunnel goes down' setting you have enabled.

EDIT 2: Whoops, having given it more thought, you probably don't need to add any custom scripting
Simply keep xxx.xxx.xxx.xxx in the Policy rules for all three VPN Clients, but enable 'Block routed clients if tunnel goes down=YES' for only VPN Client 3.

Sounds like a much easier option. I’ll go with that. Thanks again Martineau.

 

[Ratman]

Ratman, welcome; what's your model or am I more blind than I suspected? I kind of/sort of have an idea, if it's able run three OpenVPN configs, but I'm surely missing something Jack Yaz and Martineau have grasped; I read everything several times, I saw two photos for two configs, but you spoke of three. We've recently discovered our RR-AC3200 under v380.68_4 can run two concurrent (simultaneous) OpenVPN tunnels provided by this build, and likely one or two more, if we back-grade or revert the current build. The router can and does run a third (L2TP) tunnel/config without any problems as well as the server. No clients have WAN access, each of the devices provisioned to both OpenVPN clients accept DNS Exclusive, policy rules/Strict and either drops all devices from that particular tunnel if it disconnects. All tunnels have been for several days, and can direct to any of the gobal/domestic servers our provider offers, without having to turn one or the other off, simply by copying/pasting a server address and saving, if it's necessary. Not that it's anyone's business, why you'd want to shut any of your clients down, just curious. Cheers.

Hi st3v3n, my router model is Ac68u. I’ve only uploaded 2 VPN config picts and didn’t upload the third since it’s very much the same as the other 2 except it connects to a VPN server in a different region.

 

[st3v3n]

Ratman, Ah, that's what I thought. I do the same the 2nd config on the 3200, copy/paste a different server address which reuses uses the same config specs/tunnel, saves on NVRAM until something shakes down eventually with the new 382 code in the future. Heard that a fellow runs the new Asus release for the 3200 that should increase it from 64 to 128kb, but he's not able to confirm. Staying on 380.68_4 until such time. It's running too well at this point to revert to add a 3rd tunnel, but 5 configs is more than I want to fool with. Cheers.

 

[Ratman]

The issue is that you (probably) have three entries in the RPDB table
e.g.

ip rule

10101: from xxx.xxx.xxx.xxx lookup ovpnc1
10301: from xxx.xxx.xxx.xxx lookup ovpnc2
10501: from xxx.xxx.xxx.xxx lookup ovpnc3

where xxx.xxx.xxx.xxx (192.168.1.23?) is the device you wish to Selectively route via the current ACTIVE VPN client.

So if VPN Client 1 is DOWN, but VPN Client 3 is UP, then the lowest numbered RPDB rule take precedence, so rule 10101 redirects xxx.xxx.xxx.xxx to routing table ovpnc1, which, as you have specified 'Block routed clients if tunnel goes down=YES' contains directive 'prohibit default' and correctly prevents all outbound internet traffic from that device.

You will need to use the openvpn-event scripts to add an override RPDB rule when the current (i.e. last one started) VPN Client is initialising.

Get @john9527's /jffs/scripts/openvpn-event script: script v2 and create custom script:

/jffs/scripts/vpnclient1-pre-route-up

#!/bin/sh

VPN_ID=${1:4:1}                     # VPN Client

PRIO="9999"                         # Override Policy GUI generated rules

IP_ADDR="xxx.xxx.xxx.xxx"           # <<<==== Change to the device that should be routed via the ACTIVE VPN_Client

RPDB_RULE="from $IP_ADDR table 11$VPN_ID prio $PRIO"

# Check if required RPDB routing rule exists; if not then insert it
if [ -z "$(ip rule 2> /dev/null | grep -oF "$RPDB_RULE")" ];then
   ip rule add $RPDB_RULE
   ip route flush cache
fi

then simply clone this script as-is to /jffs/scripts/vpnclient2-pre-route-up and /jffs/scripts/vpnclient3-pre-route-up

NOTE: When you manually stop the VPN Client connection, you will need to explicitly remove the override RPDB rule using three custom scripts

/jffs/scripts/vpnclientX-pre-route-down.

#!/bin/sh

ip rule del prio 9999 2> /dev/null
ip route flush cache

EDIT: Updated script to always assign static RPDB prio 9999. This will ensure that the xxx.xxx.xxx.xxx device will not be allowed access via the WAN if all three VPN Clients are disconnected based on the 'Block routed clients if tunnel goes down' setting you have enabled.

EDIT 2: Whoops, having given it more thought, you probably don't need to add any custom scripting
Simply keep xxx.xxx.xxx.xxx in the Policy rules for all three VPN Clients, but enable 'Block routed clients if tunnel goes down=YES' for only VPN Client 3.

Just tried that now and works perfectly! Internet still gets blocked when all 3 VPNs our down and I can change between regions by enabling any of the 3 VPN clients. Thanks very much for your edit 2, Martineau! Saved me a lot of time from custom scripting and also solved my problem!