1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Redirect OpenVPN traffic to br1 interface, but not br0 interface

Discussion in 'Tomato Firmware' started by Userclandestine, Jun 10, 2013.

  1. Userclandestine

    Userclandestine Reformed Router Member

    Router: Asus RT-N16
    Firmware: Shibby 1.28.0000 MIPSR2-109 K26 USB AIO
    Scenario: I would like to have a 2 wireless connections, one that routes traffic through the OpenVPN client (for the purposes of watching US Netflix, etc), and one that has traffic routed normally.

    As the title states, I would like to setup my router to have traffic from devices connected to one wireless interface to route through the OpenVPN client, but all others to have normal traffic.
    Since, the devices that will access this service might change from day to day (ie: Xbox one day, partner's tablet another day, HTPC the next), I figured that having two seperate wireless connections would be the simplest solution to allowing some clients to connect to the VPN service.
    As for how this is configured in the end, I'm open to suggestions on how to make this better and I'm not bound to setting this up in a particular way (ie: If having two seperate wireless connections, and two LANs isn't the best way, I'm happy to rework things).

    What I've managed so far:
    • Router has two LANs:
      • br0 = 10.13.37.1 (client IP range: 10.13.37.100-150)
      • br1 = 10.13.36.1 (client IP range: 10.13.36.100-150)
    • Physical wireless interface: wl0 (bridged to br0 interface)
    • Second Virtual Wireless Interface: wl0.1 (bridged to br1 interface)
    • Configured the OpenVPN client to connect to my VPN service provider (tun11 interface)
    • Added iptables rules to allow br1 clients to have traffic routed through VPN.
    Here are the rules I've put in Administration->Scripts->Firewall to allow br1 traffic to route through the VPN:
    Code:
    iptables -I FORWARD -i br1 -o tun11 -j ACCEPT
    iptables -I FORWARD -i tun11 -o br1 -j ACCEPT
    iptables -I INPUT -i tun11 -j REJECT
    iptables -t nat -A POSTROUTING -i br1 -o tun11 -j MASQUERADE 
    It would seem that the last step for me is to change it so that the br0 interface does NOT route through the VPN. From my readings, I've learned that by default the OpenVPN client creates routes/rules/whatever to the br0 interface (which makes sense as a default), but I'm not sure how to go about changing it to achieve the results I'm looking for...

    Here's my iptables so far:
    Code:
    root@Tomato:/tmp/home/root# iptables --list -v
    Chain INPUT (policy DROP 157 packets, 13190 bytes)
     pkts bytes target     prot opt in     out     source               destination
       55  7117 REJECT     all  --  tun11  any     anywhere             anywhere            reject-with icmp-port-unreachable
        0     0 ACCEPT     all  --  tap21  any     anywhere             anywhere
        0     0 ACCEPT     udp  --  any    any     anywhere             anywhere            udp dpt:1194
      162  8290 DROP       all  --  any    any     anywhere             anywhere            state INVALID
     620K  438M ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
        0     0 shlimit    tcp  --  any    any     anywhere             anywhere            tcp dpt:ssh state NEW
       80  6927 ACCEPT     all  --  lo     any     anywhere             anywhere
     9862 1098K ACCEPT     all  --  br0    any     anywhere             anywhere
      186 17388 ACCEPT     all  --  br1    any     anywhere             anywhere
        0     0 ACCEPT     udp  --  any    any     anywhere             anywhere            udp spt:bootps dpt:bootpc
     1152 69281 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:51515
        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere            tcp dpt:1723
        0     0 ACCEPT     gre  --  any    any     anywhere             anywhere
     
    Chain FORWARD (policy DROP 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 ACCEPT     all  --  tun11  br1     anywhere             anywhere
      313 16769 ACCEPT     all  --  br1    tun11   anywhere             anywhere
        0     0 ACCEPT     all  --  tap21  any     anywhere             anywhere
     114K   72M            all  --  any    any     anywhere             anywhere            account: network/netmask: 10.13.37.0/255.255.255.0 name: lan
        0     0            all  --  any    any     anywhere             anywhere            account: network/netmask: 10.13.36.0/255.255.255.0 name: lan1
        0     0 ACCEPT     all  --  br0    br0     anywhere             anywhere
        0     0 ACCEPT     all  --  br1    br1     anywhere             anywhere
      148 10956 DROP       all  --  any    any     anywhere             anywhere            state INVALID
     6041  313K TCPMSS     tcp  --  any    any     anywhere             anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
     109K   72M ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
        0     0 DROP       all  --  br0    br1     anywhere             anywhere
        0     0 DROP       all  --  br1    br0     anywhere             anywhere
        0     0 wanin      all  --  vlan2  any     anywhere             anywhere
     2852  191K wanout     all  --  any    vlan2   anywhere             anywhere
     4895  302K ACCEPT     all  --  br0    any     anywhere             anywhere
        0     0 ACCEPT     all  --  br1    any     anywhere             anywhere
     
    Chain OUTPUT (policy ACCEPT 88524 packets, 116M bytes)
     pkts bytes target     prot opt in     out     source               destination
     
    Chain shlimit (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0            all  --  any    any     anywhere             anywhere            recent: SET name: shlimit side: source
        0     0 DROP       all  --  any    any     anywhere             anywhere            recent: UPDATE seconds: 60 hit_count: 4 name: shlimit side: source
     
    Chain wanin (1 references)
     pkts bytes target     prot opt in     out     source               destination
     
    Chain wanout (1 references)
     pkts bytes target     prot opt in     out     source               destination
    Any other information needed, just let me know and I can hopefully provide more.
    As for instructions, please keep in mind that today was my first day playing with iptables, and I have very limited experience with routing/networking in general.
     
  2. Userclandestine

    Userclandestine Reformed Router Member

    Bump...

    Anyone have any ideas?
     
  3. Malitiacurt

    Malitiacurt Networkin' Nut Member

  4. Userclandestine

    Userclandestine Reformed Router Member

    Thanks for the suggestion, Malitiacurt.
    I've already paid for a year's worth of VPN service through another provider, so using unblock-us, or tunlr outright isn't an option I'm willing to pay for.
    As for adding entries to the dnsmasq, wouldn't it fall over if the IPs change of any services I configure?

    Finally, even if I did setup the dnsmasq, wouldn't all data still be routed through the OpenVPN connection interface because Tomato automatically configures data on the default LAN to go through the VPN client?
     
  5. Userclandestine

    Userclandestine Reformed Router Member

    Bump 2.0

    Does anyone have ideas about how to prevent Tomato (Shibby) from redirecting traffic on the default LAN (br0) through the VPN when it is turned on?
     
  6. kthaddock

    kthaddock Network Guru Member

  7. Malitiacurt

    Malitiacurt Networkin' Nut Member

    Could be worth it to just buy a cheap router with a decent processor compatible with Tomato, load it up with a vpn build, connect it behind the main router, and have your devices that require vpn connect to it.
     
    Marcel Tunks likes this.
  8. awair

    awair Reformed Router Member

    I second that, although am also still trying to achieve what you are requesting.

    I have a 2nd router (RT-N16 running Shibby AIO) with WAN disabled, running OpenVPN. Any device requiring VPN access via this route is manually (or via dnsmasq options on any router) assigned this local IP as gateway.

    When WAN is disabled an option appears to designate the real internet gateway, by which time traffic is already "in the tunnel".

    I had previously tried to get this working with the commercial Sabai offering, but it never worked. Having switched from DD-WRT to Tomato, this was up and running within days of activating the 2nd router.

    My next plan is to filter traffic for tun11 & tun12 to use two simultaneous OpenVPN channels. Still looking for answers on that.
     
  9. Barkster

    Barkster Network Newbie Member

    did you figure this out, I'm trying to do same thing. Have two subnets on server side br0 & br1 and want only vpn traffic on br1
     
  10. eibgrad

    eibgrad Network Guru Member

    The way it *should* work is to use the Routing Policy tab. Enable the route-nopull option under Advanced, then set a From Source IP to the network on br1 (e.g., 192.168.2.0/24).

    Problem is, the Routing Policy tab has a lot of bugs (at least the last time I checked, v132). For example, using route-nopull will stop the gateway from being changed to the VPN, which is what we want, but it will also produce a DNS leak since it doesn't pull the VPN provider's DNS servers either.

    http://linksysinfo.org/index.php?threads/dns-leak.73296/

    There is (was) a bug where the alternate routing table created by Routing Policy was flushed whenever the VPN underwent a soft restart. We had to develop a fix for that.

    http://pastebin.com/sgNGsjaa

    That was some time ago (Oct 2015), and I'm not even sure it still works.

    And there's another problem where the routes from the main routing table are not copied to the alternate routing table, so while your users on br1 will use the VPN, but they will lose communications w/ br0!

    I realize that much of these details will make no sense to a lot of ppl. But the point is, Routing Policy is supposed to address this problem, but it has a lot of problems (unless some have been fixed lately and I'm unaware of it). You may be forced to do things the old school way and write your own policy based routing. I can probably dig up some examples.
     
  11. eibgrad

    eibgrad Network Guru Member

    Found some old code. This is old school compared to using the GUI, but at least it avoids some of the bugs in the GUI.

    Add the following to the Custom Configuration field of the OpenVPN client.

    Code:
    script-security 2
    route-up /jffs/route-up.sh
    route-pre-down /jffs/route-pre-down.sh
    Then install the following files in /jffs

    route-up.sh
    Code:
    #!/bin/sh -x
    (
    TID="200"
    VPN_GW="$route_vpn_gateway" # provided by OpenVPN at runtime
    WAN_GW="$(nvram get wan_gateway)"
    
    # copy main routing table to VPN routing table (exclude all
    # default gateways)
    ip route show | grep -Ev '^default|^0.0.0.0/1|^128.0.0.0/1' \
      | while read route; do
            ip route add $route table $TID
        done
    
    # add VPN as default gateway
    ip route add default via $VPN_GW table $TID
    
    # set default gateway back to WAN in main routing table
    ip route add   0.0.0.0/2 via $WAN_GW
    ip route add  64.0.0.0/2 via $WAN_GW
    ip route add 128.0.0.0/2 via $WAN_GW
    ip route add 192.0.0.0/2 via $WAN_GW
    
    # force routing system to recognize our changes
    ip route flush cache
    
    # add source IP(s)/network(s)/interface(s) to be routed over VPN
    ip rule add iif br1 table $TID
    #ip rule add from 192.168.1.7 table $TID
    #ip rule add from 192.168.1.113 table $TID
    #ip rule add from 192.168.2.0/24 table $TID
    
    # add destination IP(s)/network(s) to be routed over VPN
    #ip rule add to 111.111.111.111 table $TID
    #ip rule add to 222.222.222.0/24 table $TID
    
    # add source + destination to be routed over VPN
    #ip rule add iif br2 to 212.212.212.212 table $TID
    #ip rule add from 192.168.1.10 to 122.122.122.122 table $TID
    #ip rule add from 192.168.2.0/24 to 133.133.133.0/24 table $TID
    
    ) 2>&1 | logger -t $(basename $0)[$$]
    route-pre-down.sh
    Code:
    #!/bin/sh -x
    (
    TID="200"
    WAN_GW="$(nvram get wan_gateway)"
    
    # reset main routing table
    ip route del   0.0.0.0/2 via $WAN_GW
    ip route del  64.0.0.0/2 via $WAN_GW
    ip route del 128.0.0.0/2 via $WAN_GW
    ip route del 192.0.0.0/2 via $WAN_GW
    
    # delete VPN routing table
    ip route flush table $TID
    
    # force routing system to recognize our changes
    ip route flush cache
    
    # delete all ip rules
    while ip rule delete from 0/0 to 0/0 table $TID 2>/dev/null;
        do :; done
    
    ) 2>&1 | logger -t $(basename $0)[$$]
    Be sure to mark these executable!

    Code:
    chmod +x /jffs/route-up.sh
    chmod +x /jffs/route-pre-down.sh
     
    Last edited: Feb 22, 2017
  12. eibgrad

    eibgrad Network Guru Member

    Note, I just realized the OpenVPN client is already using the down directive for its own scripting. So I had to rename the down.sh script to route-pre-down.sh and adjusted the Custom Config field to reflect that change.

    Also had to update the scripts when I found they didn't properly handle a soft restart on the tunnel:

    killall -s SIGUSR1 openvpn

    This happens to be one of the things the Routing Policy tab in the GUI doesn't handle and why the following patch was necessary.

    http://pastebin.com/sgNGsjaa

    Also checked the latest Shibby build (v138), and it still has this and all the other bugs I found way back in v132.
     
    Last edited: Feb 22, 2017

Share This Page