OpenVPN policy routing guide?

john9527 · Jul 10, 2015

rockstead said:
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)

Bogey · Jul 11, 2015

Martineau said:
No idea why you have quoted my post , 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

rockstead · Jul 11, 2015

john9527 said:
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.

SwissDanny · Jul 12, 2015

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?

Martineau · Jul 18, 2015

Bogey said:
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.

Bogey · Jul 18, 2015

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???

Martineau · Jul 19, 2015

Bogey said:
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!

Bogey · Jul 19, 2015

Martineau said:
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'.

Martineau said:
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.

Martineau said:
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

Martineau said:
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

Martineau said:
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.

Martineau said:
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

Martineau said:
10. If it doesn't work then I give up! ....must be PEBKAC!

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.

I suspect that there must be something going on with the default settings?

Martineau · Jul 19, 2015

View attachment 4131 settings are the same

Bogey said:

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.

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?

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:

Bogey · Jul 19, 2015

Martineau said:
View attachment 4131 settings are the same

The forum software reports "The requested attachment could not be found."

Martineau said:

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?

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.

Martineau said:
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

Martineau · Jul 19, 2015

Bogey said:
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.

Bogey · Jul 20, 2015

Martineau said:
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?

Martineau said:
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#

Martineau said:
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

Martineau said:
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

Martineau said:
If table 112 (contains tun11 entries) then I've no idea.

I'm afraid it is

Can we confirm it's a bug? How do we continue, can we fix this or Merlin or Asus?

Martineau · Jul 20, 2015

Bogey said:
Yeah I see what you mean. Could that be causing the problem?

I'm afraid it is
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.

fovecifer · Jul 21, 2015

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.

Martineau · Jul 24, 2015

Martineau said:
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 ?

Martineau said:
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 · Jul 24, 2015

Martineau said:
@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

Martineau · Jul 24, 2015

Bogey said:
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!

Bogey · Jul 24, 2015

Martineau said:
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

)

Martineau · Jul 24, 2015

Bogey said:
The guy most certainly deserves/d it! (though I can't wait for him to work his magic)

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.

Bogey · Aug 6, 2015

Merlin, this is on the list of fixes for the new release, right?

Martineau said:
@RMerlin,

Should this issue be open again the main 378.55 thread ?

Martineau said:

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.

Click to expand...

Thread starter	Title	Forum	Replies	Date
D	Openvpn client dns	Asuswrt-Merlin	2	Tuesday at 4:18 PM
	WireGuard removing OpenVPN on ASUS Routers ?	Asuswrt-Merlin	2	Nov 14, 2024
T	[Help] Problems setting up OpenVPN	Asuswrt-Merlin	7	Oct 16, 2024
N	dedicated router for OpenVPN	Asuswrt-Merlin	4	Oct 16, 2024
N	Solved OpenVPN Server split tunnell config	Asuswrt-Merlin	5	Oct 13, 2024
C	Connection to router by ip fails while remote over OpenVPN	Asuswrt-Merlin	17	Sep 23, 2024
S	OpenVPN LAN access + one external IP	Asuswrt-Merlin	3	Sep 11, 2024
J	VPN director Multiple OpenVPN clients	Asuswrt-Merlin	7	Aug 31, 2024
G	OpenVPN Server log, is this in error ?	Asuswrt-Merlin	7	Aug 28, 2024
H	Extremely low speed on ac86u with openvpn client	Asuswrt-Merlin	7	Aug 25, 2024

OpenVPN policy routing guide?

Part of the Furniture

Regular Contributor

Occasional Visitor

New Around Here

Part of the Furniture

Regular Contributor

Part of the Furniture

Regular Contributor

Part of the Furniture

Regular Contributor

Attachments

Part of the Furniture

Regular Contributor

Part of the Furniture

New Around Here

Part of the Furniture

Regular Contributor

Part of the Furniture

Regular Contributor

Part of the Furniture

Regular Contributor

Similar threads

Similar threads

Support SNBForums w/ Amazon

Sign Up For SNBForums Daily Digest