Hi @stangri, still loving this piece of software, works really well! Also apologies if this issue has been posted before, I'm not entirely sure what to search for!
The exception for this is when my vpn provider doesn't do what I want them to do.
I have one vpn provider (NordVPN) and I run two tunnels to different endpoints, one local in my country and one in the US.
Mostly this works fine (and vpn-policy-routing is really cool when it does!) but it seems sometimes I get provided the same local IP address on both tunnels. This seems to cause an issue with vpn-policy-routing when defining the routes in the route tables.
Here are the relevant network interfaces from a show uci network for the nordvpn tun interfaces:
network.nordvpntun=interface
network.nordvpntun.proto='none'
network.nordvpntun.ifname='tun0'
network.nordvpntun1=interface
network.nordvpntun1.proto='none'
network.nordvpntun1.ifname='tun1'
Here is /etc/init.d/vpn-policy-routing status (with actual policy entries removed for brevity/tinfoil hat):
vpn-policy-routing 0.0.2-21 running on LEDE 17.01.4. WAN (IPv4): wan/dev/x.x.x.x.
============================================================
Dnsmasq version 2.78 Copyright (c) 2000-2017 Simon Kelley
Compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC no-ID loop-detect inotify
============================================================
Routes/IP Rules
default hostnameremoved 0.0.0.0 UG 0 0 0 eth1
IPv4 Table 201: default via x.x.x.x dev eth1
IPv4 Table 201 Rules:
32765: from all fwmark 0x10000 lookup 201
IPv4 Table 202: default via 10.1.0.1 dev tunsvr0
IPv4 Table 202 Rules:
32764: from all fwmark 0x20000 lookup 202
IPv4 Table 203: default via 10.8.8.16 dev tun0
IPv4 Table 203 Rules:
32763: from all fwmark 0x30000 lookup 203
IPv4 Table 204: default via 10.8.8.16 dev tun0
IPv4 Table 204 Rules:
32762: from all fwmark 0x40000 lookup 204
============================================================
IP Tables PREROUTING
-N VPR_PREROUTING
-A VPR_PREROUTING -m set --match-set nordvpntun1 dst -c 0 0 -j MARK --set-xmark 0x40000/0xff0000
-A VPR_PREROUTING -m set --match-set nordvpntun dst -c 0 0 -j MARK --set-xmark 0x30000/0xff0000
-A VPR_PREROUTING -m set --match-set vpnsvr0 dst -c 0 0 -j MARK --set-xmark 0x20000/0xff0000
-A VPR_PREROUTING -m set --match-set wan dst -c 0 0 -j MARK --set-xmark 0x10000/0xff0000
============================================================
Current ipsets
create wan hash:net family inet hashsize 1024 maxelem 65536 comment
create vpnsvr0 hash:net family inet hashsize 1024 maxelem 65536 comment
create nordvpntun hash:net family inet hashsize 1024 maxelem 65536 comment
create nordvpntun1 hash:net family inet hashsize 1024 maxelem 65536 comment
============================================================
Your support details have been logged to '/var/vpn-policy-routing-support'. [✓]
As you can see, the rules in the mangle table VPR_PREROUTING chain are correct, with the mark values, for 0x30000 to interface nordvpntun and 0x40000 to interface nordvpntun1.
The issue is that ip table 203 and 204 both specify device tun0, I assume because of the same client IP address of 10.8.8.16.
If I issue these commands, the issue is resolved (of course until the next time the router/vpn-policy-routing restarts):
# ip route show table 204
default via 10.8.8.16 dev tun0
# ip route del table 204 default
# ip route add table 204 default via 10.8.8.16 dev tun1
# ip route show table 204
default via 10.8.8.16 dev tun1
I have tried restarting openvpn, taking down one tun interface and bringing it back etc and I can't get a different client IP on the tunnel. Sometimes eventually I will, but it's not reliable.
Any suggestions on a setting I could change to get around this, other than manually running the commands I listed above?