What's new

VPN Director - What am I missing ?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

wrink

Regular Contributor
VPNDirector.png


The above pic shows how I have set up VPN Director - for the clients with IPs .125, .190, .85 to use OVPN1, while the .190 and .180 should use OVPN2. I have the kill switch off for both OVPN1 and 2, and "Redirect Internet traffic through tunnel" is set to "VPN Director (policy rules)" for both Clients. The respective clients are showing up correctly under "VPN Director rules related to this client" when viewed under each client.

The problem is the last 2 IPs (.190 and .180) are both showing up having externally on the internet as having connecting through OVPN1 (public IP) - and not OVPN2 (public IP) as I was expecting. Am I missing something basic here ? The problem could be my understanding of what the "Iface" should be set to, perhaps - or a rule priority setting misunderstanding. There are no other settings of clients aside from the above (there are other DHCP-clients to the AX-58U, but those flow directly to the WAN without VPNs, as desired/expected). These specific IPs are also manually fixed to the AX-58U.

Thoughts ?
 
a couple of obvious thoughts...
1. make sure you click on "Apply" button after creating a VPN Director rule.
2. Obviously both rules should have the green checkmark under the Enable column (which we do not see).
3. Try disabling OVPN1 and see what happens ?
 
Whenever you're using multiple, concurrent OpenVPN clients, you have to make 100% sure the tunnels used by each OpenVPN client are NOT overlapping! And it's esp. easy to have this happen when connected to the same VPN provider. But you can still have this happen w/ different VPN providers. In all likelihood, this is the problem.

P.S. The following commands will reveal if indeed you're having this particular problem.

Code:
ifconfig tun11
ifconfig tun12
ip route show table main
ip route show table ovpnc1
ip route show table ovpnc2
 
Last edited:
ifconfig tun11 ifconfig tun12 ip route show table main ip route show table ovpnc1 ip route show table ovpnc2
Whenever you're using multiple, concurrent OpenVPN clients, you have to make 100% sure the tunnels used by each OpenVPN client are NOT overlapping! And it's esp. easy to have this happen when connected to the same VPN provider. But you can still have this happen w/ different VPN providers. In all likelihood, this is the problem.

P.S. The following commands will reveal if indeed you're having this particular problem.

While I'm not a networking expert, what you are saying may be spot-on. Yes, I'm using the same VPN provider. Here's my output from the commands, where the bolded red lines probably indicates the problem - the second bolded line should be reading default via 10.8.8.1 dev tun1"2", etc ?

(I've switched out all my ISP and VPN provider's public ips with ab.cd.ef.gh, hopefully that doesn't make things difficult in this context)

What would be the fix ?

Thanks for your help!



admin@router:/tmp/home/root# ifconfig tun11
tun11 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.8.2 P-t-P:10.8.8.2 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:349716 errors:0 dropped:0 overruns:0 frame:0
TX packets:224748 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:373174790 (355.8 MiB) TX bytes:56745185 (54.1 MiB)

admin@router:/tmp/home/root# ifconfig tun12
tun12 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.8.4 P-t-P:10.8.8.4 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:60 (60.0 B) TX bytes:68 (68.0 B)

admin@router:/tmp/home/root# ip route show table main
default via ab.cd.ef.gh dev eth4
10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1
10.8.8.0/24 dev tun11 proto kernel scope link src 10.8.8.2
10.8.8.0/24 dev tun12 proto kernel scope link src 10.8.8.4
ab.cd.ef.gh/21 dev eth4 proto kernel scope link src ab.cd.ef.gh
ab.cd.ef.gh dev eth4 proto kernel scope link
127.0.0.0/8 dev lo scope link

admin@router:/tmp/home/root# ip route show table ovpnc1
default via 10.8.8.1 dev tun11
10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1
10.8.8.0/24 dev tun11 proto kernel scope link src 10.8.8.2
ab.cd.ef.gh/21 dev eth4 proto kernel scope link src ab.cd.ef.gh
ab.cd.ef.gh dev eth4 proto kernel scope link
127.0.0.0/8 dev lo scope link
ab.cd.ef.gh via ab.cd.ef.gh dev eth4

admin@router:/tmp/home/root# ip route show table ovpnc2
default via 10.8.8.1 dev tun11
10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1
10.8.8.0/24 dev tun11 proto kernel scope link src 10.8.8.2
ab.cd.ef.gh/21 dev eth4 proto kernel scope link src ab.cd.ef.gh
ab.cd.ef.gh dev eth4 proto kernel scope link
ab.cd.ef.gh via ab.cd.ef.gh dev eth4
127.0.0.0/8 dev lo scope link
 
Yep. It's the exact same problem as discussed in the following link (no point in repeating it all here).


Based on the upcoming 386.4 changelog, this will be corrected (see Alpha2, "
FIXED: Wrong interface might be used for the default gateway in an openvpn client routing table").

In the meantime, you can try one of the recommended fixes (e.g., manually replacing the network interface on the errant table, or using a different protocol for the two tunnels (e.g., TCP vs. UDP (sometimes that changes the tunnel IP network)).
 
Last edited:
Yep. It's the exact same problem as discussed in the following link (no point in repeating it all here).


Based on the upcoming 386.4 changelog, this will be corrected (see Alpha2, "
FIXED: Wrong interface might be used for the default gateway in an openvpn client routing table").

In the meantime, you can try one of the recommended fixes (e.g., manually replacing the network interface on the errant table, or using a different protocol for the two tunnels (e.g., TCP vs. UDP (sometimes that changes the tunnel IP network).
Thanks very much - that was very, very helpful !
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top