Running Shibby and trying to get builtin torrent client to use the VPN (Solved?)

Discussion in 'Tomato Firmware' started by AtTheAsylum, Aug 19, 2015.

  1. AtTheAsylum

    AtTheAsylum LI Guru Member

    Hi all,

    I'm running the latest version of Shibby (Tomato Firmware 1.28.0000 -131 K26ARM USB AIO-64K) on an Asus RT-AT68U and have been trying to get the builtin Transmission torrent client to use a VPN connection.

    I've done the following. In WAN Up:
    ifconfig br0:0 up

    In Transmission Custom Config:
    "bind-address-ipv4": "",

    In the the VPN client routing policy tab:
    From Source IP

    Transmission starts up, runs and connects to peers but does not use the VPN. I've checked by using the torrent downloadable from

    The VPN client works perfectly if I add my Mac's IP address to the routing policy tab. I've also tried changing the "From Source IP" to "To Destination IP" but this doesn't work either.

    Can someone shed any light on where I'm going wrong?

    Thanks :)
  2. AtTheAsylum

    AtTheAsylum LI Guru Member

    Some more info on this. I've checked that the second IP address ( is working by doing the following:

    $ssh root@

    This connects me to the router as you would expect.

    I've also checked that Transmission is listening for connections on the right IP address (port set to 51413) by running the following to port scan commands:

    $./stroke 51410 51420

    Returns: Open TCP Port: 51413

    $./stroke 51410 51420

    Returns nothing as expected.

    So it all seems to be set up correctly.
  3. AtTheAsylum

    AtTheAsylum LI Guru Member

    Ok - I think I have a solution. I'm still not sure why the VPN policy entry doesn't work but the following does:

    I added the following to my VPN custom configuration:
    route-up /mnt/ASUS/
    route-pre-down /mnt/ASUS/ does the following:
    ip rule del from table 200 #delete the existing rule (don't really need to do this).
    ip route flush table 200 #delete/flush table 200.
    ip route add default dev tun11 table 200 #create a new table 200 with a default route via the VPN (tun11).
    ip rule add from table 200 #create a new rule for IP to use table 200 (go via VPN).
    ip route flush cache #flush cache and recognize changes to the routing table. does the following:
    ip rule del from table 200 #delete existing rule (don't really need to do this).
    ip route flush table 200 #delete/flush table 200.
    ip route add default dev lo table 200 #create a new table 200 with a default route via the loopback interface (like drop - is there a better way?).
    ip rule add from table 200 ##create a new rule for IP to use table 200 (via loopback).
    ip route flush cache #flush cache and recognize changes to the routing table.

    In summary - when the VPN comes up all traffic from is directed out via the VPN. When the VPN drops all traffic from is directed to the loopback interface (basically dropped - no internet access).

    Tested by using the torrent file mentioned in the original post and by using 'ping -I' when the VPN is up and down.
    Malakai, tigs and ipse like this.
  4. BrianTren

    BrianTren New Member Member

    I'm trying to replicate this exactly on my router. Did you still end up keeping the entry for "ifconfig br0:0 up" in WAN UP?

    Edit: Believe the answer is yes. Thanks for posting all of this. I have replicated it on my setup and it appears to be working fine.
    Last edited: Nov 22, 2015
  5. eibgrad

    eibgrad Network Guru Member

  6. campbeln

    campbeln New Member Member

    FYI: I had to add "/bin/sh" in front of the scripts to get them to run, e.g.:

    route-up "/bin/sh /mnt/ASUS/"
    route-pre-down "/bin/sh/mnt/ASUS/"​

    Or you can add the following to the top of the route-*.sh files:


    Otherwise, I ended up getting this error:

    daemon.warn openvpn[21392]: WARNING: Failed running command (--route-up): could not execute external program​

    I also found that "route-up" was not showing that the script was being run in the log. "up" scripts are shown, but "route-up" don't (!?). I confirmed that the scripts are running by adding this to

    echo "Setup Complete $(date)" > /mnt/ASUS/torrents.txt​

    I also added a shutdown message in, just cause.

    I ran "ifconfig br0:0 up" from SSH ("ssh root@" with the password the same as the web UI, but note the username to SSH is always "root" even if you've changed it in the web UI). Otherwise, you'd have to restart your WAN connection/router after adding it into Administration > Scripts > WAN Up. And FYI: "ifconfig br0:0" basically makes the listed IP route back to br0 (bridge 0), so IP "interface" has two IP "numbers".

    Note that the trailing "," on this line IS VERY IMPORTANT:

    In Transmission Custom Config:
    "bind-address-ipv4": "",​

    Without it, my Transmission Web UI didn't seem to want to load. Also, Transmission is still accessed via the IP, NOT the bridged IP!
    Last edited: Oct 26, 2017
  7. PimPet

    PimPet New Member Member

    I am also trying to get this to work on my Netgear R7000 running TomatoUSB 1.28.0000

    Given that I consider myself to be quite noob I got quite far, but now I'm stuck and have no idea how to trouble shoot.

    I followed AtTheAsylum's instructions:

    In WAN Up:
    ifconfig br0:0 up

    In Transmission Custom Config:
    "bind-address-ipv4": "",

    In the the VPN client routing policy tab:
    From Source IP​

    and created the and as instructed

    I also followed campbeln's suggestion to add lines to confirm that these scripts start and shut down. Both work.

    Moreover, using $ssh root@ I can confirmt that this IP is indeed active.

    Finally, I added a second line in the routing table ( which I assigned to my smartphone for trouble shooting purposes. By downloading the torrent file from the torguard website with the smartphone I can confirm that the vpn is up, and that the routing table works. Other devices connected to the R7000 do not use the VPN but the smartphone does.

    Yet, although Transmission should be bidden to and this IP is defined in the routing table in the same way as, Transmission fails to connect through the VPN. It simply uses the ISP connection like all other devices.....

    In case it is relevant, 'Redirect Internet traffic' and route-nopull are unchecked and I've added
    route-noexec to the openvpn client custom configuration
  8. eibgrad

    eibgrad Network Guru Member

    Understand that I'm not an expert w/ Transmission. Never used it, ever. There may be nuances that I'm not considering. So keep that in mind.

    I don't really understand why this requires binding a second IP address of the same IP network to the primary bridge (br0). Binding to would seem to be sufficient. I'm not here to suggest you change it. I'm merely saying as someone who deals w/ routing issues extensively, on the surface, it just seems unnecessary.

    Adding route-noexec has almost the same effect as using route-nopull. Both directives prevent OpenVPN from changing the default gateway in the main routing table to the VPN. And unless you implement your own PBR (policy based routing), or enable Routing Policy and define what should be routed over the VPN, *nothing* will ever be routed over the VPN. That's why I found it odd the OP never mentioned using either route-nopull or route-noexec (unless it was an oversight). One or the other would seem to be necessary.

    Now in the case of the OP, he decided to implement his own PBR w/ scripts (which frankly, given all the bugs in Routing Policy, is probably a wise choice). As I said previously, because the Routing Policy tab depends on marking packets, it won't work for local processes anyway. But PBR based on using "ip rule add .." will. That's why once the OP switched to using his own scripts based on "ip rule add ...", it worked.

    Another way to have approached this would have been to NOT use route-nopull or route-noexec. That would leave the default behavior to route everything over the VPN, even for local processes on the router. And then implement your own PBR scripts that makes exceptions to be routed over the WAN. The advantage here is that you don't need to mess around w/ additional IP assignments to the LAN network interface of the router (, or so it would seem.

    You could have even used my own PBR script to implement all this.

    My script gives you the option to make exceptions to route over the WAN (when you *don't* use route-nopull or route-noexec), or make exceptions to route over the VPN (when you *do* use route-nopull or route-noexec).

    One part of the solution I find a bit odd is leaving table 200 active in the route-pre-down script, which appears to have been done to act as a kill switch. The use of loopback as the default gateway would suggest that's the intent. It might have been simpler to flush everything in the route-pre-down script (which is normally what you should do, iow, a total cleanup) and instead added the following to the firewall script.

    iptables -I OUTPUT -s -o $(nvram get wan_iface) -j REJECT
    IOW, we never allow anything bound to to use the WAN, regardless of the state of the VPN. Yes, the OP's current approach works, but it's a bit convoluted to keep routing table 200 hanging around w/ no usable routes. Not a big deal, but if you tend to be OCD about these things, it may induce an episode. :)

    As far as PimPet's immediate problem, whenever you're dealing w/ PBR like this, make sure to check the results by dumping the routing tables and rules database.

    ip route show table main
    ip route show table 200
    ip rule list
    It might reveal the problem. Don't just assume you got the results you intended!
    Last edited: Feb 10, 2018
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice