What's new

OpenVPN policy routing guide?

  • 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!

Am I doing something wrong? or is it a bug that it won't let me do my full IP range?
The inputs are in CIDR notation (it's not a range as you are trying, it's a bit mask). To cover large ranges will generally take several entries. If you google for 'range to CIDR calculator' you'll get lots of hits.

For what you want to do,

192.168.1.0/24 covers all addresses from 192.168.1.0 thru 192.168.1.255
Then add excludes (Iface set to WAN, for the router address - although this may not be required any more with some recent Merlin changes, but it won't hurt anything either)
 
Last edited:
No idea why you have quoted my post o_O, my additional RPDB fwmark rule information is only relevant if you wish to selectively route PORTS (rather than nominated devices or I/P subnets) via the VPN Client(s).

For your simple 3 PC requirements you do not even need a script, simply enter the required entries PC1, and PC2 into the Policy routing Panels for their respective VPNs.
By default PC3 should use the WAN anyway.
Ok, I wasn't very clear, you're right, my bad. Aside from selective VPNs, I also wish to selectively route ports: 587 and 4243 over WAN, my transmission ports over VPN1, 443 over VPN2.
Could you please take another look at the partial script?

Thanks,
Erwin
 
The inputs are in CIDR notation (it's not a range as you are trying, it's a bit mask). To cover large ranges will generally take several entries. If you google for 'range to CIDR calculator' you'll get lots of hits.

For what you want to do,

192.168.1.0/24 covers all addresses from 192.168.1.0 thru 192.168.1.255
Then add excludes (Iface set to WAN, for the router address - although this may not be required any more with some recent Merlin changes, but it won't hurt anything either)

Thank you, that worked perfectly.

Is there a way through the GUI to assign either VPN or WAN based on the wireless network that is selected? I think the AC68 offers 3, 2.4ghz, 5ghz, and guest.
 
Great feature, thanks. This is why I flashed the Merlin ASUSWRT. PayPal donation on its way.

I have got it working fine to make sure a given LAN IP (eg a fixed IP media server) goes via the VPN, whereas all other LAN IP go via the WAN.

However, I am struggling to get all LAN IP use the VPN for selected WAN IP. For example using a site that displays your location eg strongvpn.com, this has a subnet 216.131.64.0/19

So I put Source IP 0.0.0.0 and Destination IP 216.131.64.0/19 and Iface VPN but strongvpn.com is still showing my ISP IP and location? I tried adding a rule so the Router would go via WAN for this range, but it made no difference. EDIT: Just retried this for this example and it is now working. User malfunction I guess.

In practise, I would be using this to ensure that any LAN IP accessing Netflix or iPlayer via VPN, whereas all other traffic would use the ISP. EDIT: I guess some of these services use other IP's to do the geochecking versus delivering the content?
 
Last edited:
Ok, I wasn't very clear, you're right, my bad. Aside from selective VPNs, I also wish to selectively route ports: 587 and 4243 over WAN, my transmission ports over VPN1, 443 over VPN2.
Could you please take another look at the partial script?

Thanks,
Erwin

OK, if you have understood the RPDB routing, and have already set up the selective port routing fwmark tagging rules based on my examples in post #10

http://www.snbforums.com/threads/openvpn-policy-routing-guide.24384/#post-189754

(or the DD-WRT link you posted in the main Selective routing thread) then I'm still not clear why you are still posting that you have an issue.

Since fwmark RPDB rules are not standard in RMerlin's firmware, the only thing I can see that may be technically incorrect is that if you are still using your original openvpn-event script, then when using the 'iptables -t mangle PREROUTING' chain, unless you have different logic in openvpn-event for the starting of the VPN clients (or simply duplicate all the rules for both VPN1/VPN2) then potentially the following command

Code:
iptables   -t   mangle   -F   PREROUTING

in your script will wipe out VPN1 selective port fwmark rules if VPN2 client is started later - or vice-versa.
So my point is that you no longer need such a complex script, and I advised that it is safer to let RMerlin's VPNRouting script create/manage the RPDB tables (based on your preferred options set via the GUI), and you simply add the 3 fwmark RPDB rules to services-start, and your specific selective port iptable rules to nat-start?

I'm pretty sure selective port routing using fwmark has been successfully implemented by others by simply following the numerous straight forward guides.

Not sure what else I can help with. o_O
 
Last edited:
Thanks Martineau, I've decided to start clean and updated firmware to 378.55.

I removed the openvpn-event and firewall-start scripts.
The GUI is setup with two VPN clients, both are up and autorunning after reboot.
Redirect Internet traffic is set to 'Policy rules'.
No entries are in the 'Rules for routing client traffic through the tunnel (Max Limit : 128)'-table.

I edited services-start and it's contents are:
Code:
#!/bin/sh
cru a lightsoff "0 23 * * * /jffs/scripts/ledsoff.sh"
cru a lightson "0 7 * * * /jffs/scripts/ledson.sh"
ip rule add fwmark 1 table  111 prio 30001
ip rule add fwmark 2 table  112 prio 30002
ip rule add fwmark 3 table main prio 30003
ip route flush cache

I created nat-start (set permissions: 0755) with following contents for testing purposes:
Code:
iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.100    -p tcp --dport 443 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.100    -p tcp --dport 80      -j MARK --set-mark 2
iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.162    -p tcp --dport 443 -j MARK --set-mark 2
iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.162    -p tcp --dport 80      -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.103    -p tcp --dport 443 -j MARK --set-mark 3

What happens is that every client (192.168.0.100, 192.168.0.103, 192.168.0.162) uses VPN 1, no difference between http and https either.

When I run 'ip rule list' in terminal the results are:
Code:
0:   from all lookup local
32766:   from all lookup main
32767:   from all lookup default

When I execute in terminal
Code:
ip rule add fwmark 1 table  111 prio 30001
ip rule add fwmark 2 table  112 prio 30002
ip rule add fwmark 3 table main prio 30003
ip route flush cache
and then run 'ip rule list' in terminal the results become:
Code:
0:    from all lookup local
30001:    from all fwmark 0x1 lookup 111
30002:    from all fwmark 0x2 lookup 112
30003:    from all fwmark 0x3 lookup main
32766:    from all lookup main
32767:    from all lookup default
However, even running the iptables -t mangle -A PREROUTING commands from terminal does not change the result: VPN1 is used for everything.

What am I doing wrong???
 
Thanks Martineau, I've decided to start clean and updated firmware to 378.55.

I removed the openvpn-event and firewall-start scripts.
The GUI is setup with two VPN clients, both are up and autorunning after reboot.
Redirect Internet traffic is set to 'Policy rules'.
No entries are in the 'Rules for routing client traffic through the tunnel (Max Limit : 128)'-table.

I edited services-start and it's contents are:
Code:
#!/bin/sh
cru a lightsoff "0 23 * * * /jffs/scripts/ledsoff.sh"
cru a lightson "0 7 * * * /jffs/scripts/ledson.sh"
ip rule add fwmark 1 table  111 prio 30001
ip rule add fwmark 2 table  112 prio 30002
ip rule add fwmark 3 table main prio 30003
ip route flush cache

I created nat-start (set permissions: 0755) with following contents for testing purposes:
Code:
iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.100    -p tcp --dport 443 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.100    -p tcp --dport 80      -j MARK --set-mark 2
iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.162    -p tcp --dport 443 -j MARK --set-mark 2
iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.162    -p tcp --dport 80      -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.103    -p tcp --dport 443 -j MARK --set-mark 3

What happens is that every client (192.168.0.100, 192.168.0.103, 192.168.0.162) uses VPN 1, no difference between http and https either.

When I run 'ip rule list' in terminal the results are:
Code:
0:   from all lookup local
32766:   from all lookup main
32767:   from all lookup default

When I execute in terminal
Code:
ip rule add fwmark 1 table  111 prio 30001
ip rule add fwmark 2 table  112 prio 30002
ip rule add fwmark 3 table main prio 30003
ip route flush cache
and then run 'ip rule list' in terminal the results become:
Code:
0:    from all lookup local
30001:    from all fwmark 0x1 lookup 111
30002:    from all fwmark 0x2 lookup 112
30003:    from all fwmark 0x3 lookup main
32766:    from all lookup main
32767:    from all lookup default
However, even running the iptables -t mangle -A PREROUTING commands from terminal does not change the result: VPN1 is used for everything.

What am I doing wrong???

The whole point of RMerlin's Routing policy GUI is that all traffic by default goes via the WAN unless explicit RPDB rules indicate otherwise.

1. Remove ALL OpenVPN client directives from both the Custom Configuration panels for VPN Client1 and VPN Client2.

2. Add temporary dummy Routing Policy GUI entries for selective routing to both VPN Clients (shouldn't be necessary but may eliminate PEBKAC issues)

Code:
  DummyV1   172.16.0.1  0.0.0.0  vpn
  DummyW1  172.16.0.11  0.0.0.0  wan


and VPN Client2

Code:
 DummyV2   172.16.0.2  0.0.0.0  vpn
 DummyW2  172.16.0.21  0.0.0.0  wan

3. Reboot.

If both VPN Clients have started successfully, ALL traffic should be via the WAN?

4. Check the RPDB rules (the order matters - hence the option to use the PRIO values)

Code:
  ip rule
  ip route show table 111
  ip route show table 112

  ip route show

5. Dynamically selectively route device 192.168.0.100 to VPN2

Code:
  ip rule add from 192.168.0.100 lookup 112
  ip route flush cache
  ip rule

6. Check if ALL traffic from 192.168.0.100 is now via VPN2?

Code:
  ip rule del from 192.168.0.100 lookup 112
  ip route flush cache
  ip rule

7. Add one of your selective routing routing port rules

Code:
  iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.162    -p tcp --dport 80      -j MARK --set-mark 1

8. Perform some web activity on 192.168.0.162 is it via VPN1?

9. Check if the above rule has fired

Code:
 iptables -t mangle -L -nv --line

10. If it doesn't work then I give up! ....must be PEBKAC! :p
 
Last edited:
The whole point of RMerlin's Routing policy GUI is that all traffic by default goes via the WAN unless explicit RPDB rules indicate otherwise.

1. Remove ALL OpenVPN client directives from both the Custom Configuration panels for VPN Client1 and VPN Client2.
Done. At least... if you mean clearing the table with the Routing Policy GUI entries. BTW, Firewall is set to 'Automatic' and Create NAT on tunnel is set to 'Yes'.

2. Add temporary dummy Routing Policy GUI entries for selective routing to both VPN Clients (shouldn't be necessary but may eliminate PEBKAC issues)

Code:
  DummyV1   172.16.0.1  0.0.0.0  vpn
  DummyW1  172.16.0.11  0.0.0.0  wan


and VPN Client2

Code:
 DummyV2   172.16.0.2  0.0.0.0  vpn
DummyW2  172.16.0.21  0.0.0.0  wan

3. Reboot.

If both VPN Clients have started successfully, ALL traffic should be via the WAN?
Nope :( All traffic goes via VPN1.

4. Check the RPDB rules (the order matters - hence the option to use the PRIO values)

Code:
  ip rule
  ip route show table 111
  ip route show table 112

  ip route show
Code:
ASUSWRT-Merlin RT-AC68U_3.0.0.4 Fri Jul 17 03:17:04 UTC 2015
Erwin@RT-AC68U:/tmp/home/root# ip rule
0:    from all lookup local
1001:    from 172.16.0.11 lookup main
1201:    from 172.16.0.1 lookup 111
1401:    from 172.16.0.21 lookup main
1601:    from 172.16.0.2 lookup 112
32766:    from all lookup main
32767:    from all lookup default

Erwin@RT-AC68U:/tmp/home/root#   ip route show table 111
192.168.178.1 dev eth0  scope link
109.232.227.148 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
10.30.0.0/16 dev tun11  proto kernel  scope link  src 10.30.0.47
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.30.0.1 dev tun11
128.0.0.0/1 via 10.30.0.1 dev tun11
default via 10.30.0.1 dev tun11

Erwin@RT-AC68U:/tmp/home/root#   ip route show table 112
192.168.178.1 dev eth0  scope link
104.219.251.46 via 192.168.178.1 dev eth0
109.232.227.148 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
10.30.0.0/16 dev tun11  proto kernel  scope link  src 10.30.0.47
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.30.0.1 dev tun11
128.0.0.0/1 via 10.30.0.1 dev tun11
default via 10.30.0.1 dev tun11

Erwin@RT-AC68U:/tmp/home/root#   ip route show
192.168.178.1 dev eth0  scope link
104.219.251.46 via 192.168.178.1 dev eth0
109.232.227.148 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
10.30.0.0/16 dev tun11  proto kernel  scope link  src 10.30.0.47
10.30.0.0/16 dev tun12  proto kernel  scope link  src 10.30.0.18
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.30.0.1 dev tun11
128.0.0.0/1 via 10.30.0.1 dev tun11
default via 192.168.178.1 dev eth0

5. Dynamically selectively route device 192.168.0.100 to VPN2

Code:
  ip rule add from 192.168.0.100 lookup 112
  ip route flush cache
  ip rule

6. Check if ALL traffic from 192.168.0.100 is now via VPN2?
Unfortunately not. Still VPN1
Code:
Erwin@RT-AC68U:/tmp/home/root# ip rule add from 192.168.0.100 lookup 112
Erwin@RT-AC68U:/tmp/home/root#   ip route flush cache
Erwin@RT-AC68U:/tmp/home/root#   ip rule
0:    from all lookup local
1000:    from 192.168.0.100 lookup 112
1001:    from 172.16.0.11 lookup main
1201:    from 172.16.0.1 lookup 111
1401:    from 172.16.0.21 lookup main
1601:    from 172.16.0.2 lookup 112
32766:    from all lookup main
32767:    from all lookup default

Code:
  ip rule del from 192.168.0.100 lookup 112
  ip route flush cache
  ip rule

7. Add one of your selective routing routing port rules

Code:
  iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.162    -p tcp --dport 80      -j MARK --set-mark 1

8. Perform some web activity on 192.168.0.162 is it via VPN1?
Yes it is, but all traffic is via VPN1, so this doesn't count, right?
I ran also:
Code:
  iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.162    -p tcp --dport 80      -j MARK --set-mark 0
to see if WAN is finally used.

9. Check if the above rule has fired

Code:
 iptables -t mangle -L -nv --line
Code:
Erwin@RT-AC68U:/tmp/home/root# iptables -t mangle -L -nv --line
Chain PREROUTING (policy ACCEPT 83 packets, 13701 bytes)
num   pkts bytes target     prot opt in     out     source               destination        
1        0     0 MARK       all  --  !eth0  *       0.0.0.0/0            192.168.178.13       MARK set 0xb400
2     5553 2241K BWDPI_FILTER  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0          
3      834  124K MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            source IP range 192.168.0.162-192.168.0.162 tcp dpt:80 MARK set 0x2
4      670 70804 MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            source IP range 192.168.0.162-192.168.0.162 tcp dpt:80 MARK and 0x0

Chain INPUT (policy ACCEPT 49 packets, 5518 bytes)
num   pkts bytes target     prot opt in     out     source               destination        

Chain FORWARD (policy ACCEPT 24 packets, 4657 bytes)
num   pkts bytes target     prot opt in     out     source               destination        

Chain OUTPUT (policy ACCEPT 41 packets, 7682 bytes)
num   pkts bytes target     prot opt in     out     source               destination        

Chain POSTROUTING (policy ACCEPT 65 packets, 12339 bytes)
num   pkts bytes target     prot opt in     out     source               destination        

Chain BWDPI_FILTER (1 references)
num   pkts bytes target     prot opt in     out     source               destination        
1        0     0 DROP       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp spt:68 dpt:67
2        0     0 DROP       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68

10. If it doesn't work then I give up! ....must be PEBKAC! :p
Must be! :( Maybe I should ask my wife to run through it again...
Anyway, I also loaded factory settings and started from scratch. And I tried both with and without the custom script services-start containing only the fwmark rules. With those rules the 2nd VPN was always used. :confused:
I suspect that there must be something going on with the default settings?
 
View attachment 4131 settings are the same
Done. At least... if you mean clearing the table with the Routing Policy GUI entries. BTW, Firewall is set to 'Automatic' and Create NAT on tunnel is set to 'Yes'.

Nope :( All traffic goes via VPN1.


Code:
ASUSWRT-Merlin RT-AC68U_3.0.0.4 Fri Jul 17 03:17:04 UTC 2015
Erwin@RT-AC68U:/tmp/home/root# ip rule
0:    from all lookup local
1001:    from 172.16.0.11 lookup main
1201:    from 172.16.0.1 lookup 111
1401:    from 172.16.0.21 lookup main
1601:    from 172.16.0.2 lookup 112
32766:    from all lookup main
32767:    from all lookup default

Erwin@RT-AC68U:/tmp/home/root#   ip route show table 111
192.168.178.1 dev eth0  scope link
109.232.227.148 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
10.30.0.0/16 dev tun11  proto kernel  scope link  src 10.30.0.47
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.30.0.1 dev tun11
128.0.0.0/1 via 10.30.0.1 dev tun11
default via 10.30.0.1 dev tun11

Erwin@RT-AC68U:/tmp/home/root#   ip route show table 112
192.168.178.1 dev eth0  scope link
104.219.251.46 via 192.168.178.1 dev eth0
109.232.227.148 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
10.30.0.0/16 dev tun11  proto kernel  scope link  src 10.30.0.47
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.30.0.1 dev tun11
128.0.0.0/1 via 10.30.0.1 dev tun11
default via 10.30.0.1 dev tun11

Erwin@RT-AC68U:/tmp/home/root#   ip route show
192.168.178.1 dev eth0  scope link
104.219.251.46 via 192.168.178.1 dev eth0
109.232.227.148 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
10.30.0.0/16 dev tun11  proto kernel  scope link  src 10.30.0.47
10.30.0.0/16 dev tun12  proto kernel  scope link  src 10.30.0.18
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.30.0.1 dev tun11
128.0.0.0/1 via 10.30.0.1 dev tun11
default via 192.168.178.1 dev eth0

Unfortunately not. Still VPN1
Code:
Erwin@RT-AC68U:/tmp/home/root# ip rule add from 192.168.0.100 lookup 112
Erwin@RT-AC68U:/tmp/home/root#   ip route flush cache
Erwin@RT-AC68U:/tmp/home/root#   ip rule
0:    from all lookup local
1000:    from 192.168.0.100 lookup 112
1001:    from 172.16.0.11 lookup main
1201:    from 172.16.0.1 lookup 111
1401:    from 172.16.0.21 lookup main
1601:    from 172.16.0.2 lookup 112
32766:    from all lookup main
32767:    from all lookup default

Yes it is, but all traffic is via VPN1, so this doesn't count, right?
I ran also:
Code:
  iptables -t mangle -A PREROUTING -i br0 -m iprange --src-range 192.168.0.162    -p tcp --dport 80      -j MARK --set-mark 0
to see if WAN is finally used.


Code:
Erwin@RT-AC68U:/tmp/home/root# iptables -t mangle -L -nv --line
Chain PREROUTING (policy ACCEPT 83 packets, 13701 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 MARK       all  --  !eth0  *       0.0.0.0/0            192.168.178.13       MARK set 0xb400
2     5553 2241K BWDPI_FILTER  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0
3      834  124K MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            source IP range 192.168.0.162-192.168.0.162 tcp dpt:80 MARK set 0x2
4      670 70804 MARK       tcp  --  br0    *       0.0.0.0/0            0.0.0.0/0            source IP range 192.168.0.162-192.168.0.162 tcp dpt:80 MARK and 0x0

Chain INPUT (policy ACCEPT 49 packets, 5518 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 24 packets, 4657 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 41 packets, 7682 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 65 packets, 12339 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain BWDPI_FILTER (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 DROP       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp spt:68 dpt:67
2        0     0 DROP       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68

Must be! :( Maybe I should ask my wife to run through it again...
Anyway, I also loaded factory settings and started from scratch. And I tried both with and without the custom script services-start containing only the fwmark rules. With those rules the 2nd VPN was always used. :confused:
I suspect that there must be something going on with the default settings?

The VPN default rules are not being deleted by RMerlin's firmware... and your table 112 (VPN2) appears to be a clone of table 111 (VPN1) rather than have the expected entries for tun12????? WTF? o_O

Here in my Syslog you can see one of my PS3s and dummy RPDB rules being added after the two DEFAULT rules for 0.0.0.0/1 and 128.0.0.0/1 are automatically deleted when I start VPN Client1

Code:
Jul  9 16:28:14 RT-AC56U daemon.notice openvpn[18581]: add_route_ipv6(): not adding 2000::/3, no IPv6 on if tun11

Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Configuring policy rules for client 1
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Creating VPN routing table
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from routing tables
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from routing tables
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Added 10.88.8.142 to 0.0.0.0 through VPN to routing policy
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Added 172.16.0.1 to 0.0.0.0 through VPN to routing policy
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Added 172.16.0.2 to 0.0.0.0 through VPN to routing policy
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Added 172.16.0.3 to 0.0.0.0 through WAN to routing policy
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Tunnel re-established, restoring WAN access to clients
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Completed routing policy configuration

So either U still have options defined in the Custom Configuration for VPN1/VPN2 or a stupid custom script? that is preventing RMerlin's firmware from working correctly.
Did you delete/rename openvpn-event?

My settings are the same and Accept DNS Configuration is set to 'Relaxed' and my Custom Config panel for VPN1/VPN2 is as shown:

2015-07-19_19-06-40.jpg
 
Last edited:
The forum software reports "The requested attachment could not be found."

The VPN default rules are not being deleted by RMerlin's firmware... and your table 112 (VPN2) appears to be a clone of table 111 (VPN1) rather than have the expected entries for tun12????? WTF? o_O

Here in my Syslog you can see one of my PS3s and dummy RPDB rules being added after the two DEFAULT rules for 0.0.0.0/1 and 128.0.0.0/1 are automatically deleted when I start VPN Client1

Code:
Jul  9 16:28:14 RT-AC56U daemon.notice openvpn[18581]: add_route_ipv6(): not adding 2000::/3, no IPv6 on if tun11

Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Configuring policy rules for client 1
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Creating VPN routing table
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from routing tables
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from routing tables
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Added 10.88.8.142 to 0.0.0.0 through VPN to routing policy
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Added 172.16.0.1 to 0.0.0.0 through VPN to routing policy
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Added 172.16.0.2 to 0.0.0.0 through VPN to routing policy
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Added 172.16.0.3 to 0.0.0.0 through WAN to routing policy
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Tunnel re-established, restoring WAN access to clients
Jul  9 16:28:15 RT-AC56U user.warn openvpn-routing: Completed routing policy configuration
One difference between yours and mine is that there are two extra lines in mine "Removing rule 1001 from routing policy" and "Removing rule 1201 from routing policy". I've attached my full system log file.

So either U still have options defined in the Custom Configuration for VPN1/VPN2 or a stupid custom script? that is preventing RMerlin's firmware from working correctly.
Did you delete/rename openvpn-event?

My settings are the same and Accept DNS Configuration is set to 'Relaxed' and my Custom Config panel for VPN1/VPN2 is as shown:

View attachment 4132
Yes, I deleted the openvpn-event script (immediately as soon as you mentioned the script as a possible party pooper). I changed from Exclusive to Relaxed but that didn't seem to make any difference. The 3 entries in custom config are created by loading the .ovpn file (which in turn is generated by AirVPN). See the attached snapshot of my screen.
(I can't get the forum software to display a readable image, so I shared it on tinypic):
http://i59.tinypic.com/akkis1.png
 

Attachments

  • log.txt
    39.8 KB · Views: 710
  • ASUS Wireless Router RT-AC68U - OpenVPN Client Settings 2015-07-19 22-31-45.png
    ASUS Wireless Router RT-AC68U - OpenVPN Client Settings 2015-07-19 22-31-45.png
    203.1 KB · Views: 635
Last edited:
The forum software reports "The requested attachment could not be found."

One difference between yours and mine is that there are two extra lines in mine "Removing rule 1001 from routing policy" and "Removing rule 1201 from routing policy". I've attached my full system log file.

Yes, I deleted the openvpn-event script (immediately as soon as you mentioned the script as a possible party pooper). I changed from Exclusive to Relaxed but that didn't seem to make any difference. The 3 entries in custom config are created by loading the .ovpn file (which in turn is generated by AirVPN). See the attached snapshot of my screen.
(I can't get the forum software to display a readable image, so I shared it on tinypic):
http://i59.tinypic.com/akkis1.png

The default rules to be deleted can be seen to be added for VPN1, and correctly immediately deleted by RMerlin's script but the default rules appear to be added for VPN2...but NOT deleted?

Jul 19 22:16:32 openvpn[1028]: /usr/sbin/ip route add 0.0.0.0/1 via 10.4.0.1
Jul 19 22:16:32 openvpn[1028]: /usr/sbin/ip route add 128.0.0.0/1 via 10.4.0.1
Jul 19 22:16:32 openvpn-routing: Configuring policy rules for client 1
Jul 19 22:16:32 openvpn-routing: Creating VPN routing table
Jul 19 22:16:32 openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from routing tables
Jul 19 22:16:32 openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from routing tables
Jul 19 22:16:32 openvpn-routing: Removing rule 1001 from routing policy
Jul 19 22:16:32 openvpn-routing: Removing rule 1201 from routing policy
Jul 19 22:16:33 openvpn-routing: Added 172.16.0.1 to 0.0.0.0 through VPN to routing policy
Jul 19 22:16:33 openvpn-routing: Added 172.16.0.11 to 0.0.0.0 through WAN to routing policy
Jul 19 22:16:33 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Jul 19 22:16:33 openvpn-routing: Completed routing policy configuration
Jul 19 22:16:33 openvpn[1028]: Initialization Sequence Completed
Jul 19 22:16:33 openvpn[1039]: /usr/sbin/ip route add 199.241.146.178/32 via 192.168.178.1
Jul 19 22:16:33 openvpn[1039]: /usr/sbin/ip route add 0.0.0.0/1 via 10.4.0.1
Jul 19 22:16:33 openvpn[1039]: /usr/sbin/ip route add 128.0.0.0/1 via 10.4.0.1
Jul 19 22:16:33 openvpn-routing: Configuring policy rules for client 2
Jul 19 22:16:33 openvpn-routing: Creating VPN routing table
Jul 19 22:16:33 openvpn-routing: Removing rule 1401 from routing policy
Jul 19 22:16:33 openvpn-routing: Removing rule 1601 from routing policy
Jul 19 22:16:33 openvpn-routing: Added 172.16.0.2 to 0.0.0.0 through VPN to routing policy
Jul 19 22:16:33 openvpn-routing: Added 172.16.0.21 to 0.0.0.0 through WAN to routing policy
Jul 19 22:16:33 openvpn-routing: Tunnel re-established, restoring WAN access to clients
Jul 19 22:16:33 openvpn-routing: Completed routing policy configuration

All I can suggest is that you disable the auto-start of the VPN Clients.

Reboot

On restart check the status of the RPDB rules and the route tables.

Then start VPN1 manually, and check the status of the RPDB tables and the route tables.

Nothing should be sent via VPN1.

Then start VPN2 manually, and check the status of the RPDB tables and the route tables.

Nothing should be sent via VPN1/VPN2.

If table 112 (contains tun11 entries) then I've no idea.
 
Last edited:
The default rules to be deleted can be seen to be added for VPN1, and correctly immediately deleted by RMerlin's script but the default rules appear to be added for VPN2...but NOT deleted?
Yeah I see what you mean. Could that be causing the problem?

All I can suggest is that you disable the auto-start of the VPN Clients.

Reboot

On restart check the status of the RPDB rules and the route tables.
Done, the results are:
Code:
ASUSWRT-Merlin RT-AC68U_3.0.0.4 Fri Jul 17 03:17:04 UTC 2015
Erwin@RT-AC68U:/tmp/home/root# ip rule
0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default
Erwin@RT-AC68U:/tmp/home/root# ip route show table 111
Erwin@RT-AC68U:/tmp/home/root# ip route show table 112
Erwin@RT-AC68U:/tmp/home/root# ip route show
192.168.178.1 dev eth0  scope link
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
127.0.0.0/8 dev lo  scope link
default via 192.168.178.1 dev eth0
Erwin@RT-AC68U:/tmp/home/root#

Then start VPN1 manually, and check the status of the RPDB tables and the route tables.

Nothing should be sent via VPN1.
Correct. VPN1 is up and traffic goes via WAN (client area at AirVPN confirms this).
Code:
Erwin@RT-AC68U:/tmp/home/root# ip rule
0:    from all lookup local
1001:    from 172.16.0.11 lookup main
1201:    from 172.16.0.1 lookup 111
32766:    from all lookup main
32767:    from all lookup default
Erwin@RT-AC68U:/tmp/home/root# ip route show table 111
192.168.178.1 dev eth0  scope link
213.152.161.100 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
10.4.0.0/16 dev tun11  proto kernel  scope link  src 10.4.7.165
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.4.0.1 dev tun11
128.0.0.0/1 via 10.4.0.1 dev tun11
default via 10.4.0.1 dev tun11
Erwin@RT-AC68U:/tmp/home/root# ip route show table 112
Erwin@RT-AC68U:/tmp/home/root# ip route show
192.168.178.1 dev eth0  scope link
213.152.161.100 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
10.4.0.0/16 dev tun11  proto kernel  scope link  src 10.4.7.165
127.0.0.0/8 dev lo  scope link
default via 192.168.178.1 dev eth0
Then start VPN2 manually, and check the status of the RPDB tables and the route tables.

Nothing should be sent via VPN1/VPN2.
VPN1 and VPN2 are up. Traffic goes via... VPN1 :( Client area at AirVPN confirms this.
Code:
Erwin@RT-AC68U:/tmp/home/root# ip rule
0:    from all lookup local
1001:    from 172.16.0.11 lookup main
1201:    from 172.16.0.1 lookup 111
1401:    from 172.16.0.21 lookup main
1601:    from 172.16.0.2 lookup 112
32766:    from all lookup main
32767:    from all lookup default
Erwin@RT-AC68U:/tmp/home/root# ip route show table 111
192.168.178.1 dev eth0  scope link
213.152.161.100 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
10.4.0.0/16 dev tun11  proto kernel  scope link  src 10.4.7.165
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.4.0.1 dev tun11
128.0.0.0/1 via 10.4.0.1 dev tun11
default via 10.4.0.1 dev tun11
Erwin@RT-AC68U:/tmp/home/root# ip route show table 112
192.168.178.1 dev eth0  scope link
213.152.161.100 via 192.168.178.1 dev eth0
199.241.146.178 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
10.4.0.0/16 dev tun11  proto kernel  scope link  src 10.4.7.165
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.4.0.1 dev tun11
128.0.0.0/1 via 10.4.0.1 dev tun11
default via 10.4.0.1 dev tun11
Erwin@RT-AC68U:/tmp/home/root# ip route show
192.168.178.1 dev eth0  scope link
213.152.161.100 via 192.168.178.1 dev eth0
199.241.146.178 via 192.168.178.1 dev eth0
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.13
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.1
10.4.0.0/16 dev tun11  proto kernel  scope link  src 10.4.7.165
10.4.0.0/16 dev tun12  proto kernel  scope link  src 10.4.13.46
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.4.0.1 dev tun11
128.0.0.0/1 via 10.4.0.1 dev tun11
default via 192.168.178.1 dev eth0
If table 112 (contains tun11 entries) then I've no idea.
I'm afraid it is :confused:
Can we confirm it's a bug? How do we continue, can we fix this or Merlin or Asus?
 
Yeah I see what you mean. Could that be causing the problem?

I'm afraid it is :confused:
Can we confirm it's a bug? How do we continue, can we fix this or Merlin or Asus?

Selective RPDB routing definitely works for a single VPN Client.

Not sure when it got broken, but I know it was working for .53 firmware, but I haven't used selective RPDB routing for both VPN1 and VPN2 concurrently for quite a while.

RMerlin's code:

Code:
# Delete existing VPN routes that were pushed by server on table main
    NET_LIST=$(ip route show|awk '$2=="via" && $3==ENVIRON["route_vpn_gateway"] && $4=="dev" && $5==ENVIRON["dev"] {print $1}')
    for NET in $NET_LIST
    do
        ip route del $NET dev $dev
        logger -t "openvpn-routing" "Removing route for $NET to $dev from routing tables"
    done

does not appear to fire for whichever VPN client is started second.....so from what I can tell, an incorrect /invalid route table is being presented to his code so a very very dirty hack may be to replace

Code:
&& $5==ENVIRON["dev"]

with

&& ($5=="tun11" ||  $5=="tun12")

effectively force

Code:
ip route del 0.0.0.0/1
ip route del 128.0.0.0/1

Looks like a bug to me. :(
 
Last edited:
This is a great feature!
but, it's rule depend on IP, not domain name.

In OpenWRT, you could use dnsmasq + ipset, so that the rules
could depend on domain names.

So I wish someone could add ipset support for dnsmasq.
 
Selective RPDB routing definitely works for a single VPN Client.

Not sure when it got broken, but I know it was working for .53 firmware, but I haven't used selective RPDB routing for both VPN1 and VPN2 concurrently for quite a while.

RMerlin's code:

Code:
# Delete existing VPN routes that were pushed by server on table main
    NET_LIST=$(ip route show|awk '$2=="via" && $3==ENVIRON["route_vpn_gateway"] && $4=="dev" && $5==ENVIRON["dev"] {print $1}')
    for NET in $NET_LIST
    do
        ip route del $NET dev $dev
        logger -t "openvpn-routing" "Removing route for $NET to $dev from routing tables"
    done

does not appear to fire for whichever VPN client is started second.....so from what I can tell, an incorrect /invalid route table is being presented to his code so a very very dirty hack may be to replace

Code:
&& $5==ENVIRON["dev"]

with

&& ($5=="tun11" ||  $5=="tun12")

effectively force

Code:
ip route del 0.0.0.0/1
ip route del 128.0.0.0/1

Looks like a bug to me. :(

@Bogey, Did you ever see a reply from RMerlin in response to this bug?



@RMerlin,

Should this issue be open again the main 378.55 thread ?
Selective RPDB routing definitely works for a single VPN Client.

Not sure when it got broken, but I know it was working for .53 firmware, but I haven't used selective RPDB routing for both VPN1 and VPN2 concurrently for quite a while.

RMerlin's code:

Code:
# Delete existing VPN routes that were pushed by server on table main
    NET_LIST=$(ip route show|awk '$2=="via" && $3==ENVIRON["route_vpn_gateway"] && $4=="dev" && $5==ENVIRON["dev"] {print $1}')
    for NET in $NET_LIST
    do
        ip route del $NET dev $dev
        logger -t "openvpn-routing" "Removing route for $NET to $dev from routing tables"
    done

does not appear to fire for whichever VPN client is started second.....so from what I can tell, an incorrect /invalid route table is being presented to his code so a very very dirty hack may be to replace

Code:
&& $5==ENVIRON["dev"]

with

&& ($5=="tun11" ||  $5=="tun12")

effectively force

Code:
ip route del 0.0.0.0/1
ip route del 128.0.0.0/1

Looks like a bug to me. :(
 
@Bogey, Did you ever see a reply from RMerlin in response to this bug?
Yes, I contacted Merlin with a message. His reply:
RMerlin said:
Policy-based routing is only available in my firmware, so there's nothing for Asus to fix there.

I'll take a look sometime later - I'm not spending much time developing these days since I'm currently on vacation.
Well have to have just a little patience :)
 
Yes, I contacted Merlin with a message. His reply:Well have to have just a little patience :)

OK, thanks for the feedback.

RMerlin will hopefully come back refreshed from his vacation! :)
 
The guy most certainly deserves/d it! ;) (though I can't wait for him to work his magic:D)

Well if you can't wait, then you can always take a copy of his read-only /usr/sbin/vpnrouting.sh script and create a modified read-write copy to fix routing table 112 etc. ;)
 
Merlin, this is on the list of fixes for the new release, right?
@RMerlin,

Should this issue be open again the main 378.55 thread ?
Selective RPDB routing definitely works for a single VPN Client.

Not sure when it got broken, but I know it was working for .53 firmware, but I haven't used selective RPDB routing for both VPN1 and VPN2 concurrently for quite a while.

RMerlin's code:

Code:
# Delete existing VPN routes that were pushed by server on table main
    NET_LIST=$(ip route show|awk '$2=="via" && $3==ENVIRON["route_vpn_gateway"] && $4=="dev" && $5==ENVIRON["dev"] {print $1}')
    for NET in $NET_LIST
    do
        ip route del $NET dev $dev
        logger -t "openvpn-routing" "Removing route for $NET to $dev from routing tables"
    done

does not appear to fire for whichever VPN client is started second.....so from what I can tell, an incorrect /invalid route table is being presented to his code so a very very dirty hack may be to replace

Code:
&& $5==ENVIRON["dev"]

with

&& ($5=="tun11" ||  $5=="tun12")

effectively force

Code:
ip route del 0.0.0.0/1
ip route del 128.0.0.0/1

Looks like a bug to me. :(
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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