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

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 192.168.1.2 up

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

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

    Transmission starts up, runs and connects to peers but does not use the VPN. I've checked by using the torrent downloadable from http://torguard.net/checkmytorrentipaddress.php.

    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 (192.168.1.2) is working by doing the following:

    $ssh root@192.168.1.2

    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 192.168.1.2 51410 51420

    Returns: Open TCP Port: 51413

    $./stroke 192.168.1.1 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-up1.sh
    route-pre-down /mnt/ASUS/route-pre-down1.sh

    route-up1.sh does the following:
    ip rule del from 192.168.1.2 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 192.168.1.2 table 200 #create a new rule for IP 192.168.1.2 to use table 200 (go via VPN).
    ip route flush cache #flush cache and recognize changes to the routing table.

    route-pre-down1.sh does the following:
    ip rule del from 192.168.1.2 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 192.168.1.2 table 200 ##create a new rule for IP 192.168.1.2 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 192.168.1.2 is directed out via the VPN. When the VPN drops all traffic from 192.168.1.2 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 192.168.1.2 google.com' 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 192.168.1.2 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-up1.sh"
    route-pre-down "/bin/sh/mnt/ASUS/route-pre-down1.sh"​

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

    #!/bin/sh​

    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 route-up1.sh:

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

    I also added a shutdown message in route-pre-down1.sh, just cause.

    I ran "ifconfig br0:0 192.168.1.2 up" from SSH ("ssh root@192.168.1.1" 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": "192.168.1.2",​

    Without it, my Transmission Web UI didn't seem to want to load. Also, Transmission is still accessed via the 192.168.1.1:9091 IP, NOT the bridged 192.168.1.2:9091 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 192.168.1.2 up

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

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

    and created the route-up1.sh and route-predown1.sh 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@192.168.1.2 I can confirmt that this IP is indeed active.


    Finally, I added a second line in the routing table (192.168.1.6) 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 192.168.1.2 and this IP is defined in the routing table in the same way as 192.168.1.6, 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 192.168.1.1 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 (192.168.1.2), or so it would seem.

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

    https://pastebin.com/xEziw8Pq

    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.

    Code:
    iptables -I OUTPUT -s 192.168.1.2 -o $(nvram get wan_iface) -j REJECT
    IOW, we never allow anything bound to 192.168.1.2 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.

    Code:
    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

Share This Page