Menu
What's new
By:
Filters Better Search

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!

I just spent an hour doing tests with two simultaneous OpenVPN clients, and everything is working as expected for me.

Client 1: German vpnbook server, with my Win7 VM forced through it
Client 2: Canadian vpnbook server, with my Linux VM forced through it

After a reboot, visiting WhatismyIP:

Win7 VM gives me a German IP
Linux VM gives me a Canadian IP (not my ISP's)
My desktop (unrouted) gives me my ISP's IP

If you want to do more tinkering with this:

1) Make a copy of /usr/sbin/vpnrouting.sh to /jffs/
2) Create an init-start script that will do a "mount -o bind /jffs/vpnrouting.sh /usr/sbin/vpnrouting.sh"
3) Insert more logger debugging entries into /jffs/vpnrouting.sh

That way, you will be able to get additional debug info even at boot time (init-start runs as soon as the JFFS partition becomes available, which is very early in the boot process).
 
Last edited:
Thanks for checking this out Merlin. Good thing it works on your side, hopefully you can help me achieve the same.
So I did #1, #2 too (I created a file init-start in /jffs/scripts and chmod'ed 755), what would you suggest to add as #3?
 
This is the way I do it with two vpns routing selectively over each. I haven't switched to the GUI for policy based routing because, well, if it isn't broke don't fix it.

Not sure if this will help you or if you want to do it this way.


/jffs/scripts/vpnclientup.sh
Code: 
#!/bin/sh

# Only for tun11
case $1 in
tun11)
A=1
VPNTBL=20${A}
ip route add table $VPNTBL default via $4 dev $1
ip rule add priority ${A}10 from 10.100.1.185 to 10.100.1.0/24 lookup main
ip rule add priority ${A}10 from 10.100.1.185 to 192.168.1.0/24 lookup main
ip rule add priority ${A}20 from 10.100.1.185 lookup $VPNTBL

ip route flush cache
;;
tun12)
A=2
VPNTBL=20${A}
ip route add table $VPNTBL default via $4 dev $1
ip rule add priority ${A}10 from 10.100.1.15 to 10.100.1.0/24 lookup main
ip rule add priority ${A}20 from 10.100.1.15 lookup $VPNTBL
ip rule add priority ${A}10 from 10.100.1.16 to 10.100.1.0/24 lookup main
ip rule add priority ${A}20 from 10.100.1.16 lookup $VPNTBL

ip route flush cache
;;
esac

exit 0

/jffs/scripts/vpnclientdown.sh
Code: 
#!/bin/sh

# Only for tun11
case $1 in
tun11)
A=1
VPNTBL=20${A}
ip route flush table $VPNTBL
ip route list table $VPNTBL | tail -1 | while read l; do
   ip route del table $VPNTBL
done
ip rule | egrep "lookup $VPNTBL|^${A}" | awk -F: '{print $2}' | while read l; do
  ip rule delete $l
done
ip route flush cache
;;
tun12)
A=2
VPNTBL=20${A}
ip route flush table $VPNTBL
ip route list table $VPNTBL | tail -1 | while read l; do
   ip route del table $VPNTBL
done
ip rule | egrep "lookup $VPNTBL|^${A}" | awk -F: '{print $2}' | while read l; do
  ip rule delete $l
done
ip route flush cache
esac

exit 0

add this to both your openvpn client configs:
Code: 
script-security 2
up /jffs/scripts/vpnclientup.sh
down /jffs/scripts/vpnclientdown.sh

Also make sure you
Code: 
chmod +x /jffs/scripts/vpnclient*.sh

Also select "redirect internet traffic:no" as this will be doing it for you. I've wanted to convert to Merlin's shiny routing policy functionality but haven't had time but maybe this will help you move forward.

I know you want to do port based routing and you can do that by substituiting the rules for port based ones.
 
Last edited:
I am having the same problems on my AC68U. internal IP addresses in the policy for VPN client 2 use VPN client 1 instead.

Richard
 
I had been using an openvpn up script on my n66u but as I have now purchased an ac68u I thought I would give the new gui features a bash.
I see it explicitly states in the read me that "Block routed clients if tunnel goes down" is no use to man nor beast until the vpn is initiated in the first place and goes down for some reason, but if I get a power cut or whatever then there is a window of time clients access the normal wan, or if I manually stop the vpn client all clients can use the wan.

Previously I was using a firewall-start script with a command such as:
"iptables -I FORWARD -o ppp0 -s 192.168.0.5 -j DROP" however this now seems to do nothing now, same if it is in nat-start.

Has anyone experienced the same and have a work around?
 
bilboSNB said:
I see it explicitly states in the read me that "Block routed clients if tunnel goes down" is no use to man nor beast until the vpn is initiated in the first place and goes down for some reason, but if I get a power cut or whatever then there is a window of time clients access the normal wan, or if I manually stop the vpn client all clients can use the wan.
Click to expand...

That was taken care of in 378.55 as far as I can remember.


Sent from my Nexus 4 using Tapatalk
 
Sorry I appear to have been talking out of my butt when I said it was in the readme :oops: I must have picked that info up at an earlier point.

Should the clients assigned to the vpn still be blocked when the vpn client is manually switched off? This is how I normally test the block rule is working which currently it is not eg for 192.168.0.52 this is accessing the normal wan when I flick the client off.

current rules:

admin@RT-AC68U:/tmp/home/root# ip rule
0: from all lookup local
1201: from 192.168.0.23 lookup 111
1202: from 192.168.0.5 lookup 111
1203: from 192.168.0.52 lookup 111
1204: from 192.168.0.16 to 173.194.0.0/16 lookup 111
1205: from 192.168.0.16 to 216.58.192.0/19 lookup 111
1206: from 192.168.0.16 to 216.58.208.0/20 lookup 111
1207: from 192.168.0.13 to 173.194.0.0/16 lookup 111
1208: from 192.168.0.13 to 216.58.192.0/19 lookup 111
1209: from 192.168.0.13 to 216.239.32.0/19 lookup 111
1210: from 192.168.0.13 to 216.58.208.0/20 lookup 111
1211: from 192.168.0.14 to 173.194.0.0/16 lookup 111
1212: from 192.168.0.14 to 216.58.192.0/19 lookup 111
1213: from 192.168.0.14 to 216.239.32.0/19 lookup 111
1214: from 192.168.0.14 to 216.58.208.0/20 lookup 111
1215: from 192.168.0.9 to 173.194.0.0/16 lookup 111
1216: from 192.168.0.9 to 216.58.192.0/19 lookup 111
1217: from 192.168.0.9 to 216.239.32.0/19 lookup 111
1218: from 192.168.0.9 to 216.58.208.0/20 lookup 111
1219: from 192.168.0.17 to 173.194.0.0/16 lookup 111
1220: from 192.168.0.17 to 216.58.192.0/19 lookup 111
1221: from 192.168.0.17 to 216.239.32.0/19 lookup 111
1222: from 192.168.0.17 to 216.58.208.0/20 lookup 111
32766: from all lookup main
32767: from all lookup default
 
bilboSNB said:
Sorry I appear to have been talking out of my butt when I said it was in the readme :oops: I must have picked that info up at an earlier point.

Should the clients assigned to the vpn still be blocked when the vpn client is manually switched off? This is how I normally test the block rule is working which currently it is not eg for 192.168.0.52 this is accessing the normal wan when I flick the client off.

current rules:

admin@RT-AC68U:/tmp/home/root# ip rule
0: from all lookup local
1201: from 192.168.0.23 lookup 111
1202: from 192.168.0.5 lookup 111
1203: from 192.168.0.52 lookup 111
1204: from 192.168.0.16 to 173.194.0.0/16 lookup 111
1205: from 192.168.0.16 to 216.58.192.0/19 lookup 111
1206: from 192.168.0.16 to 216.58.208.0/20 lookup 111
1207: from 192.168.0.13 to 173.194.0.0/16 lookup 111
1208: from 192.168.0.13 to 216.58.192.0/19 lookup 111
1209: from 192.168.0.13 to 216.239.32.0/19 lookup 111
1210: from 192.168.0.13 to 216.58.208.0/20 lookup 111
1211: from 192.168.0.14 to 173.194.0.0/16 lookup 111
1212: from 192.168.0.14 to 216.58.192.0/19 lookup 111
1213: from 192.168.0.14 to 216.239.32.0/19 lookup 111
1214: from 192.168.0.14 to 216.58.208.0/20 lookup 111
1215: from 192.168.0.9 to 173.194.0.0/16 lookup 111
1216: from 192.168.0.9 to 216.58.192.0/19 lookup 111
1217: from 192.168.0.9 to 216.239.32.0/19 lookup 111
1218: from 192.168.0.9 to 216.58.208.0/20 lookup 111
1219: from 192.168.0.17 to 173.194.0.0/16 lookup 111
1220: from 192.168.0.17 to 216.58.192.0/19 lookup 111
1221: from 192.168.0.17 to 216.239.32.0/19 lookup 111
1222: from 192.168.0.17 to 216.58.208.0/20 lookup 111
32766: from all lookup main
32767: from all lookup default
Click to expand...


You need to show the contents of the routing table before you start the VPN1 Client

Code: 
ip   route   show   table   111

and again after you start the VPN1 Client.

Hopefully you will see the 'default' route/ 'prohibit' blocking statement disappear/reappear when the VPN1 Client is DOWN.
 
Thanks Martineau, is there a blocking statment here?

Code: 
off
ASUSWRT-Merlin RT-AC68U_3.0.0.4 Fri Jul 17 03:17:04 UTC 2015
admin@RT-AC68U:/tmp/home/root# ip   route   show   table   111
194.187.250.x via 195.10.125.x dev ppp0
78.110.172.x via 195.10.125.x dev ppp0
195.10.125.x dev ppp0  proto kernel  scope link  src 37.18.137.x
194.187.250.x via 195.10.125.x dev ppp0
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

on
admin@RT-AC68U:/tmp/home/root# ip   route   show   table   111
194.187.250.x via 195.10.125.x dev ppp0
78.110.172.x via 195.10.125.x dev ppp0
195.10.125.x dev ppp0  proto kernel  scope link  src 37.18.137.x
194.187.250.x via 195.10.125.x dev ppp0
10.129.21.x dev tun11  proto kernel  scope link  src 10.129.21.x
194.187.250.x via 195.10.125.x dev ppp0
10.129.0.1 via 10.129.21.x dev tun11
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
0.0.0.0/1 via 10.129.21.x dev tun11
128.0.0.0/1 via 10.129.21.x dev tun11
default via 10.129.21.x dev tun11
 
Last edited:
I have been doing some more experimenting and it looks like manually switching off the vpn removes the block rule as when I deliberately put in my username and password wrong so the vpn fails I do get blocked:
Code: 
admin@RT-AC68U:/tmp/home/root# ip   route   show   table   111
195.10.125.x dev ppp0  proto kernel  scope link  src 46.31.x.x
194.187.250.x via 195.10.125.x dev ppp0
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
prohibit default

On this basis how could I maintain the block when the vpn client is turned off, a down script?
 
bilboSNB said:
I have been doing some more experimenting and it looks like manually switching off the vpn removes the block rule as when I deliberately put in my username and password wrong so the vpn fails I do get blocked:
Code: 
admin@RT-AC68U:/tmp/home/root# ip   route   show   table   111
195.10.125.x dev ppp0  proto kernel  scope link  src 46.31.x.x
194.187.250.x via 195.10.125.x dev ppp0
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
prohibit default

On this basis how could I maintain the block when the vpn client is turned off, a down script?
Click to expand...

RMerlin's script should handle this blocking for you.

Or yes you could replicate his script /usr/sbin/vpnrouting.sh to perform the same blocking based on your criteria

Also, immediately after the router is booted his script will create the appropriate VPN Client routing table (111 or 112) containing the blocking directive.

However, in my personal experience, occasionally after a reboot (1 in 100?), sometimes the RPDB rule table and the associated VPN Client routing table are not correct :confused:
 
I manually switch off the VPN client to change servers, etc and the prohibit default rule is inserted into table 111 as intended. not sure why you're not seeing that. perhaps you have the line "explicit exit notify" in your custom config? That screws things up. Merlin has done some fixes so that DNS is cleaned up even with that line but I've seen other problems still exist.
 
So there is an issue with my setup then. What fw version are you on?
I did have the explicit exit line
Code: 
auth MD5
ping 5
ping-exit 60
ping-timer-rem
explicit-exit-notify 2
script-security 2
remote-cert-tls server
route-delay 5
tun-mtu 1500
fragment 1300
mssfix 1300

However I changed to this and I am still getting the same behaviour:

Code: 
auth MD5
script-security 2
remote-cert-tls server
tun-mtu 1500
fragment 1300
mssfix 1300
 
Its something to do with my rules, removing all but one and the block works as it should. Why would that be?
 
After more experimenting there seems to be a finite number of entries that can entered before blocking stops working from what I can tell: 20.

21 and it stops, back to 20 and it works again, can anyone else confirm?
 
Last edited:
well, determining a cause is progress. I hope Merlin is seeing this.
 
bilboSNB said:
After more experimenting there seems to be a finite number of entries that can entered before blocking stops working from what I can tell: 20.

21 and it stops, back to 20 and it works again, can anyone else confirm?
Click to expand...

Your posted ip rule output does show more than 20 entries, so from the firmware side of thing everything looks fine. Are you sure that 21st rule doesn't overlap/conflict with any of the other rules?
 
Thanks Eric, the blocking was not working when I had those rules in place, prohibit default was not appearing
Yes sure about the 21st rule not overlapping, I used an arbitrary rule "test 192.168.0.203 0.0.0.0 VPN" and blocking stopped. However on this occasion when I removed that rule blocking did not work again straight away I had to stop and start the vpn a couple of times.
I will remove my rules and put in new random rules:
192.168.0.50 0.0.0.0 VPN
192.168.0.51 0.0.0.0 VPN
etc etc see what happens and report back.

edit, same thing happens. Could it be a timing thing?
 
Last edited:
Still seeing more strange things with this. Most recently all my devices started to think they were in the UK despite clearly having Policies set up for just two IP addresses. Also I find that I can turn off one of the two clients, and then find it back on again later. I believe I am consistent in using "Apply".
 
You must log in or register to reply here.

Similar threads

eibgrad
OpenVPN Client: mishandled route directives
Replies
7
Views
926
eibgrad
eibgrad
joebloogs
Routing rules for Dual WAN?
Replies
2
Views
339
Tech9
Tech9
M
OpenVPN / site to site with special security/routing constraints
Replies
7
Views
1K
elorimer
E
R
DomainVPNRouting Domain VPN Routing v3.0.4 ***Release***
2 3
Replies
54
Views
4K
smallkeungz
S
A
Policy-based port routing to bypass NordVPN client
Replies
10
Views
2K
Don->
D
Similar threads
Thread starter Title Forum Replies Date
Viktor Jaep OpenVPN Client Connection through existing OpenVPN Router Connection causes DISCONNECT Asuswrt-Merlin 0
M 2 separate clients on OpenVPN server Asuswrt-Merlin 4
D Solved Openvpn client dns Asuswrt-Merlin 2
D WireGuard removing OpenVPN on ASUS Routers ? Asuswrt-Merlin 2
T [Help] Problems setting up OpenVPN Asuswrt-Merlin 7
N dedicated router for OpenVPN Asuswrt-Merlin 4
N Solved OpenVPN Server split tunnell config Asuswrt-Merlin 5
C Connection to router by ip fails while remote over OpenVPN Asuswrt-Merlin 17
S OpenVPN LAN access + one external IP Asuswrt-Merlin 3
J VPN director Multiple OpenVPN clients Asuswrt-Merlin 7

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!

Members online

Total: 747 (members: 26, guests: 721)
Top