Need 1 IP/Device to Bypass VPN

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking
Author Message
Zeke351
DD-WRT Novice


Joined: 17 Jan 2015
Posts: 4

PostPosted: Sat Jan 17, 2015 22:53    Post subject: Need 1 IP/Device to Bypass VPN Reply with quote
I have searched, read, tried, failed, started over and failed again for a day now so I need some help. I need one device on my network to bypass the vpn.

I am running a Netgear WNDR3700 with DD-WRT v24-sp2 (03/25/13) std - build 21061. I have the Openvpn client on the router connecting through PIA working fine.

I just need the device at IP 192.168.0.20 to bypass the VPN. I just do not have enough experience to wrap my head around the policy based routing entries to make it work.

Any specific help would be appreciated.

Zeke[/img]
Sponsor
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 7414

PostPosted: Sun Jan 18, 2015 1:08    Post subject: Reply with quote
On the face of it, this isn’t too difficult a problem to solve. The issue is well understood and a solution is available. However, the problem is that dd-wrt’s implementation of OpenVPN makes it far more complicated than it should be. Let me explain.

Using policy based routing and scripting, you create an alternate routing table, copy the default routing table (main) over to the new routing table (minus the VPN default gateway and routes), and configure ip rules to force certain IPs to use that alternate routing table. All and all pretty simple (even if it’s new to you).

OpenVPN has a built-in feature that allows your own scripts to be called in response to certain OpenVPN events. For example, once OpenVPN has fixed up the routing table by adding itself as the new default gateway, it calls the script associated w/ the route-up directive. Likewise, when OpenVPN is about to shutdown, it calls the script associated w/ the route-pre-down directive. You can add these directives to the OpenVPN client additional config field to take any actions you deem necessary in response to these events.

Code:
script-security 2
route-up /jffs/route-up.sh
route-pre-down /jffs/route-down.sh


All well and good, and a perfect opportunity to implement our own policy based routing changes. But there’s a problem. dd-wrt uses these same directives to setup its own firewall rules. And to make matters worse, it does this by passing these directives as command line arguments. And that has the effect of overriding any attempt by YOU to use those same directives on the GUI!

IOW, the solution is known but dd-wrt makes it nearly impossible to implement. IMO, it’s just poor design. You don’t see this w/ tomato, for example, because it’s smart enough not to use the route-up and route-pre-down directives for itself.

Bottom line; we have to use a non-traditional (and less preferred) solution. And that involves the command line. We wait for OpenVPN to start running after reboot and restart it ourselves, except we now pass our own scripts using these same directives. And those scripts also need to call the original dd-wrt scripts so the firewall is established correctly.

I’m sure much of this sounds incomprehensible to some ppl. But that’s why no one is able to give you a simple straight-forward answer. Due to this poor implementation of OpenVPN by dd-wrt, we‘re forced to take over the entire process to correct it.

To that end, I’ve provided a script that should handle all of this. But it’s still a WIP (work in progress). I decided to dump it out here anyway in hopes that someone was game to trying it. It just requires that you edit the script to include the IP(s) you wanted forced back over the WAN.

Code:
# route-up.sh
ip rule add from 192.168.1.126 table $TID
ip rule add from 192.168.1.133 table $TID
...


Code:
# route-pre-down.sh
ip rule del from 192.168.1.126 table $TID
ip rule del from 192.168.1.133 table $TID
...


You add the script to the startup script (as-is), save it, and reboot. Once the OpenVPN client has been killed and restarted (it just waits for 120 seconds under the assumption that should be adequate, but that might require adjustment), your IP(s) should be rerouted over the WAN.

Code:
#!/bin/sh
OVPN_ROOT="/tmp/my_openvpncl"
OVPN_ROUTE_UP="$OVPN_ROOT/route-up.sh"
OVPN_ROUTE_DOWN="$OVPN_ROOT/route-down.sh"
OVPN_RESTART="$OVPN_ROOT/restart.sh"

[ -e $OVPN_ROOT ] || mkdir -p $OVPN_ROOT

cat << "EOF" > $OVPN_ROUTE_UP
#!/bin/sh
. /tmp/openvpncl/route-up.sh
# ------------- begin your script --------------->
TID=200
VPN_IF="$dev" # provided by OpenVPN at runtime

ip route flush table $TID > /dev/null 2>&1
ip route show table main | \
        grep -Ev '^0.0.0.0/1|^128.0.0.0/1' | \
        grep -v "$VPN_IF" \
  | while read route; do
        ip route add $route table $TID
    done
ip route flush cache
ip rule add from 192.168.1.126 table $TID
ip rule add from 192.168.1.133 table $TID
# <------------- end your script -----------------
EOF
chmod +x $OVPN_ROUTE_UP

cat << "EOF" > $OVPN_ROUTE_DOWN
#!/bin/sh
# ------------- begin your script --------------->
TID=200
ip rule del from 192.168.1.126 table $TID
ip rule del from 192.168.1.133 table $TID
ip route flush table $TID
ip route flush cache
# <------------- end your script -----------------
. /tmp/openvpncl/route-down.sh
EOF
chmod +x $OVPN_ROUTE_DOWN

cat << EOF > $OVPN_RESTART
#!/bin/sh
sleep 120
killall openvpn
sleep 10
openvpn --config /tmp/openvpncl/openvpn.conf --route-up $OVPN_ROUTE_UP --route-pre-down $OVPN_ROUTE_DOWN --daemon
EOF
chmod +x $OVPN_RESTART
$OVPN_RESTART &


NOTE: One other solution that’s much easier is to NOT make OpenVPN the default gateway, then use the policy based routing field of the OpenVPN client to identify those IPs that should use the VPN. Of course, this is itself becomes a hassle if most of your IPs should be forced over the VPN. But it does work and only requires the GUI.


Last edited by eibgrad on Sun Jan 18, 2015 5:36; edited 1 time in total
Zeke351
DD-WRT Novice


Joined: 17 Jan 2015
Posts: 4

PostPosted: Sun Jan 18, 2015 4:24    Post subject: Reply with quote
WOW! Thanks for the reply eibgrad. All that for 1 IP? I think I may be in over my head on this one. I will take a closer look at it and see if I can figure it out.

Thanks.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 7414

PostPosted: Sun Jan 18, 2015 5:34    Post subject: Reply with quote
Yep. Unbelievable, eh.
Zeke351
DD-WRT Novice


Joined: 17 Jan 2015
Posts: 4

PostPosted: Fri Jan 23, 2015 1:45    Post subject: Reply with quote
eibgrad wrote:
NOTE: One other solution that’s much easier is to NOT make OpenVPN the default gateway, then use the policy based routing field of the OpenVPN client to identify those IPs that should use the VPN. Of course, this is itself becomes a hassle if most of your IPs should be forced over the VPN. But it does work and only requires the GUI.


eibgrad - Sorry I have been away this week. Looking at the last note you made, how specifically would I go about this? Lets assume 18 IP Addresses 192.168.0.3 to 192.168.0.20 with 192.168.0.20 being the one device I don't want forced back over the vpn?

Zeke
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 7414

PostPosted: Fri Jan 23, 2015 4:28    Post subject: Reply with quote
Pretty simple, if not necessary elegant.

Don’t use the "redirect-gateway def1" directive, which can be specified either in your OpenVPN client config, or PUSH’d by the OpenVPN server. This means that by default, you do NOT send any source IPs over the VPN.

Now you add those source IPs you *do* want forced over the VPN to the policy based routing field:

192.168.0.3
192.168.0.4
192.168.0.5
192.168.0.6
...
192.168.0.20

That's it. So unless a source IP (or a network, 192.168.0.0/24) is specified, it continues to use the WAN.

As I said, it's not elegant or even convenient in cases where everything should use the VPN w/ one or two exceptions. It would be much nicer (and efficient) if you could just force everything over the VPN by default and list the exceptions. But the dd-wrt implementation isn't very friendly in that regard. That policy based routing field ALWAYS points to the VPN, regardless whether or not you specify the redirect-gateway directive. Ugh.

So that’s leaves you with two bad options; either completely take over the process yourself, or do as above and at least be able to continue using the GUI.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum