Following on from the thread on selective routing with OpenVPN, I am providing a similar solution that works for PPTP VPN client connections.
This post details the method and a simple PPTP start-up script. In a following post (few days as am busy) I will post a more detailed script that allows for VPN state detection etc.
The following has been tested on a RT-N66U running 3.0.0.4.374.38_2-em. I am confident that it will work on other devices. In fact, the method is generic. Because of this I will go into the method in some detail, in the hope that others will adapt it for other Linux based platforms. So please feel free to contribute and distribute! Chuck me a "thanks" if it's been of any use to you.
I do *not* in any way claim that I have discovered anything. I have simply brought together, with my own investigations, a simple solution. Too often I see simple made hard. I like it the other way round.
The problem: When running the PPTP client on the N66U, all traffic is diverted via said interface. This is by design, and keeps things fairly secure. With selective routing, or split tunneling as it's also known, traffic can be routed.
Prior to running the VPN client, your routing table may look similar to this:
Yes, yes. I know I am double-NAT'ing. It's not relevant.
After the VPN is started:
A new default route is added on the ppp5 interface and all traffic will go that way. The 78.x.x.x address is the VPN destination address - though not important.
What is important is to take note of the VPN interface name. In my case ppp5. With this we can enter the following:
And that's it! Almost.
You will have to do a little working out math wise for the second line for the route -n add. But you should be able to work out the netmask by looking at the second table after the VPN has been started.
Looking at the routing table now we see ...
The first line removes the default route for ppp5.
The second line brings ppp5 back up, but not as a default route.
The third applies a default route to table 3 via ppp5.
At this stage *all* traffic will go via the "normal" route. Not the VPN. To do that we add ip rules.
ip rule add from 192.168.1.70 table 3 pref 300
The above says any traffic from 192.168.1.70 go via table 3, which happens to have the default route for ppp5. The pref is important (not so the number itself).
To route via table 3 you can use ip rule add to/from whatever. Just make sure any rules or conditions relating to ppp5 go in table 3.
The example above is for my PS3. But it's a blanket rule - all traffic from the PS3 will go via the VPN. No so good for logging into the PlayStation Network. No problem, we can do this:
ip rule add to 198.107.128.0/22 table main
ip rule add to 198.107.156.0/22 table main
That will route traffic to the PSN via the normal interface. Further, it will do so because the pref 300 has a lower priority than the rules in main which take higher priority. ip rule shows this better:
0: from all lookup local
300: from 192.168.1.70 lookup 3
32764: from all to 198.107.156.0/22 lookup main
32765: from all to 198.107.128.0/22 lookup main
32766: from all lookup main
32767: from all lookup default
Using the script below (donated to me by someone who wishes to remain anonymous), we can start up a PPTP connection when the router is booted. Add the ifconfig and the ip route add default dev commands after the sleep 20, followed by rules to add.
Next post in a few days will have a better startup script, plus some notes on DNS when using the above.
A final note: This method will allow you to access the router via the WAN.
Regards
PS. This has been edited by myself to reflect a more elegant, and I hope, more generic method of removing and adding the VPN interface.
This post details the method and a simple PPTP start-up script. In a following post (few days as am busy) I will post a more detailed script that allows for VPN state detection etc.
The following has been tested on a RT-N66U running 3.0.0.4.374.38_2-em. I am confident that it will work on other devices. In fact, the method is generic. Because of this I will go into the method in some detail, in the hope that others will adapt it for other Linux based platforms. So please feel free to contribute and distribute! Chuck me a "thanks" if it's been of any use to you.
I do *not* in any way claim that I have discovered anything. I have simply brought together, with my own investigations, a simple solution. Too often I see simple made hard. I like it the other way round.
The problem: When running the PPTP client on the N66U, all traffic is diverted via said interface. This is by design, and keeps things fairly secure. With selective routing, or split tunneling as it's also known, traffic can be routed.
Prior to running the VPN client, your routing table may look similar to this:
Code:
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.5.1 * 255.255.255.255 UH 0 0 0 eth0
192.168.5.0 * 255.255.255.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 br0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 192.168.5.1 0.0.0.0 UG 0 0 0 eth0After the VPN is started:
Code:
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.5.1 * 255.255.255.255 UH 0 0 0 eth0
78.x.x.x 192.168.5.1 255.255.255.255 UGH 0 0 0 eth0
192.168.5.0 * 255.255.255.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 br0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default 10.255.240.1 0.0.0.0 UG 0 0 0 ppp5
default 192.168.5.1 0.0.0.0 UG 0 0 0 eth0What is important is to take note of the VPN interface name. In my case ppp5. With this we can enter the following:
Code:
ip route delete default via 10.255.240.1 dev ppp5
route -n add -net 10.255.240.0 netmask 255.255.255.0 ppp5
ip route add default dev ppp5 table 3You will have to do a little working out math wise for the second line for the route -n add. But you should be able to work out the netmask by looking at the second table after the VPN has been started.
Looking at the routing table now we see ...
Code:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.5.1 * 255.255.255.255 UH 0 0 0 WAN
78.x.x.x 192.168.5.1 255.255.255.255 UGH 0 0 0 WAN
192.168.5.0 * 255.255.255.0 U 0 0 0 WAN
10.255.240.0 * 255.255.255.0 U 0 0 0 ppp5
192.168.1.0 * 255.255.255.0 U 0 0 0 LAN
default 192.168.5.1 0.0.0.0 UG 1 0 0 WANThe second line brings ppp5 back up, but not as a default route.
The third applies a default route to table 3 via ppp5.
At this stage *all* traffic will go via the "normal" route. Not the VPN. To do that we add ip rules.
ip rule add from 192.168.1.70 table 3 pref 300
The above says any traffic from 192.168.1.70 go via table 3, which happens to have the default route for ppp5. The pref is important (not so the number itself).
To route via table 3 you can use ip rule add to/from whatever. Just make sure any rules or conditions relating to ppp5 go in table 3.
The example above is for my PS3. But it's a blanket rule - all traffic from the PS3 will go via the VPN. No so good for logging into the PlayStation Network. No problem, we can do this:
ip rule add to 198.107.128.0/22 table main
ip rule add to 198.107.156.0/22 table main
That will route traffic to the PSN via the normal interface. Further, it will do so because the pref 300 has a lower priority than the rules in main which take higher priority. ip rule shows this better:
0: from all lookup local
300: from 192.168.1.70 lookup 3
32764: from all to 198.107.156.0/22 lookup main
32765: from all to 198.107.128.0/22 lookup main
32766: from all lookup main
32767: from all lookup default
Using the script below (donated to me by someone who wishes to remain anonymous), we can start up a PPTP connection when the router is booted. Add the ifconfig and the ip route add default dev commands after the sleep 20, followed by rules to add.
Next post in a few days will have a better startup script, plus some notes on DNS when using the above.
Code:
#!/bin/sh
logger "$0 $1"
nvram set vpnc_dnsenable_x="1"
nvram set vpnc_heartbeat_x="vpn server"
nvram set vpnc_pppoe_passwd="password"
nvram set vpnc_pppoe_username="user name"
nvram set vpnc_pptp_options_x="+mppe-128"
nvram set vpnc_proto="pptp"
service restart_vpncall
sleep 20Regards
PS. This has been edited by myself to reflect a more elegant, and I hope, more generic method of removing and adding the VPN interface.
Last edited:
