Under normal circumstances, where the OP reported using the Merlin software on an unsupported platform (I'm not even sure that's the case, frankly), I would NOT reply. But I'm going to make a rare exception in this case because it's a good opportunity to identify a bug in how the router appears to be mishandling the default gateway w/ the VPN Director.
The problem here is that the OP is using the same OpenVPN provider for each OpenVPN client. And as often happens, that can lead to routing ambiguity when more than one tunnel is using the same IP network (e.g., 10.16.0.0/255.255.0.0).
In this case, I believe FastestVPN is using a subnet topology and the same gateway IP (10.16.0.1). What ends up happening is the ovpnc1 and ovpnc3 routing tables are *both* pointing to the same network interface (either tun11 or tun13, just depends which gets established first) when establishing 10.16.0.1 as the default gateway, when normally each would be pointing to its own unique gateway IP on its respective tunnel (tun11 and tun13). But the routing system gets confused because of the network overlap.
All that said, w/ the new VPN Director, this shouldn't matter anymore, provided the router includes the tunnel's network interface when creating the default route for each table.
IOW, presently, the router seems to be using the following command for adding the default route to these tables.
Code:
ip route add default via 10.16.0.1 table ovpnc1
ip route add default via 10.16.0.1 table ovpnc3
… when it should really include the network interface as well.
Code:
ip route add default via 10.16.0.1 dev tun11 table ovpnc1
ip route add default via 10.16.0.1 dev tun13 table ovpnc3
NOW it doesn't matter that the tunnels overlap, since each is managed separately, within its own routing table. But failing to include the network interface means the routing system is left to determine which network interface is relevant. And as such, it's defaulting to the one that established a route to 10.16.0.1 first, either opvnc1 or ovpnc3, for both tables. If you dump the respective tables, you'll see what I mean.
Code:
ip route show table ovpnc1
ip route show table ovpnc3
In my own case, I'm using ovpnc2 and ovpnc3, but the effects are the same. Each table points to 10.16.0.1 on the tun12 network interface.
Code:
admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc2
185.240.246.99 via 192.168.63.1 dev vlan2
192.168.63.1 dev vlan2 proto kernel scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
192.168.63.0/24 dev vlan2 proto kernel scope link src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev vlan2 metric 1
10.16.0.0/16 dev tun12 proto kernel scope link src 10.16.0.24
127.0.0.0/8 dev lo scope link
default via 10.16.0.1 dev tun12
admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc3
185.240.246.99 via 192.168.63.1 dev vlan2
192.168.63.1 dev vlan2 proto kernel scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
192.168.63.0/24 dev vlan2 proto kernel scope link src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev vlan2 metric 1
10.16.0.0/16 dev tun12 proto kernel scope link src 10.16.0.24
127.0.0.0/8 dev lo scope link
default via 10.16.0.1 dev tun12 # WRONG!! Should be tun13
But if you manually replace the errant default route in ovpnc3 w/ the proper network interface, things will start working correctly.
Code:
ip route rep default via 10.16.0.1 dev tun13 table ovpnc3
Again, I'm only mentioning it in this thread because it's the best opportunity to explain the problem w/ the VPN Director and how to correct it. The VPN Director, if it handles this properly, can eliminate these IP tunnel overlaps *provided* it includes the network interface when adding the default route to the ovpncx tables. At present, it doesn't seem to be doing so.
