Transmission torrent client through VPN

Installing and Using OpenWrt
1

Hi All,
EDIT: Forgot to indicate that I am referring to the transmission client for LEDE-Openwrt.
Just wondering, has anybody had any success routing torrent traffic through a vpn tunnel?

I am running the latest Openwrt. Tried vpn-policy-routing. Choosing to route a local (or a remote) port isn’t sufficient.

I’ve also tried the bind_ipv4 address option for transmission. If I set that value to the IP of my tun1 interface, transmission does accept it and it can initiate/download transfers and connect to peers. However, when inspecting the output of ‘top’ command, the output is showing almost 0 cpu usage for the openvpn process. (which is not the case if, say, I am actually using the VPN).

Any ideas?

Thanks

2

Also connecting to a VPN-server you usually obtain a private IPv4-address, so you need to own the VPN-server to create firewall rules forwarding BitTorrent-traffic to your client, otherwise you won't be able to keep the upload/download-ratio.

3

Thanks.

The script linked basically updates the IP of the tun0/tun1 interface automatically when it changes. Also confirms my suspecion that the ‘bind_ipv4_address’ option only forces transmission to listen to peer connections through that interface, but not route actual traffic.

The other part of the script tutorial routes all traffic through VPN (transmission or not), which is not what I want...

As for port-forwarding, I do have a port open through my VPN provider which I intend to use for torrent clients.

4

route-up.sh creates additional routing table and adds routes and rules to utilize it.
Also it removes the routes, which redirect all traffic, although there's a more elegant way:
https://openwrt.org/docs/guide-user/services/vpn/openvpn/extras#disable_gateway_redirection

5

From the script (after deleting the routes first)

# Add the route to direct all traffic using the the vpn routing table to the tunX interface
echo ip route add default dev ${dev} table vpn
/bin/ip route add default dev ${dev} table vpn

this seems to me that it’s redirecting all traffic to go through the tun interface.

I am confused.

6

The point is routing table vpn is separated from routing table main, so it should affect only those apps, which bind VPN-address specifically, such as Transmission configured with transmission-helper.sh.

7

Sorry, I get it now!

I adapted that script to automatically assign the IP to transmission on route-up. Tested it and it’s working correctly.

I then used vpn policy-based routing package for Openwrt to create a rule that directs any traffic from source (10.0.0.0/8) to my set-up VPN tunnel. (my VPN local addresses are 10.XXX.XXX.XXX and my local network is 192.168.1.1/24)

In your opinion, what’s the best way to verify that the torrent traffic is passing through?

8

Well you can head over to Realtime Graphs in LuCI and under Traffic tab look at the tun0/tun1 interface and it should show you any activity.

9

Yeah nothing there... I guess it’s still not working...

10

I am not really sure if this will work. You see your VPN client already has 10.0.0.0/8 range. So setting up the IP in VPR is useless because if someone from the same range would be connecting to access internet it would be routed through that VPN otherwise all the traffic would go through WAN.

Where do you use your transmission client? The same router or any other AP?

Edit: I think you should first see how transmission accesses internet from router. Best guess would be through 127.0.0.1 subnet which is basically the same as router's local interface. If thats the case then you will see a lot of connections in the LuCI Realtime Graphs -> Connections page being made through 127.0.0.1 or YourRouter.lan. I dont use transmission myself, switched to aria2, but if the above is the case for you then tell VPR to route all the traffic from the router itself through VPN and this would force transmission to use VPN.

Beware that if you have any ports open to access your router remotely then also create those rules in VPR accordingly so that traffic passes through as you'd like it to.

11

EDIT: Transmission is running on the router itself.

Honestly I am so confused by what is going on, thank you for your help!

So I took a step back and set the bind_ipv4 address of the transmission-daemon to 192.168.1.1.
That essentially means the traffic is originating from the router. Confirmed by checking the connections tab as you said, it’s routername.lan that’s connecting to all those peers.

OPBR has an option to replicate a policy in the OUTPUT chain, meaning if you create a policy with an unset local address, it will apply to traffic originating from the router.

So setting that didn’t work- I still don’t see any traffic passing throug tun1 interface with realtime graphs when torrent is active......

12

Have you tried setting 192.168.1.1 as local address in vpn-policy-based-routing package?

13

Yeah was sure I tried that, but I just tried it again. Still passing through eth0.

14

I also tried what I could with my aria2 but no traffic passes through VPN. I think someone else with more experience can help on this matter.

Edit:
I found something here: https://www.linksysinfo.org/index.php?threads/route-only-specific-ports-through-vpn-openvpn.37240/ but I had to reverse engineer it. So I think following is working for me.

# get vpn ip
VPN_IP=$(ip addr show eth0 | grep 'inet ' | awk '{print $2}' | cut -f1 -d'/')

# flush table 100 and rules
ip route flush table 100
ip route del default table 100
ip rule del fwmark 1 table 100
ip route flush cache

# create table 100
ip route add default table 100 via $VPN_IP
ip rule add fwmark 100 table 100
ip route flush cache

# create torrent rules
iptables -t mangle -I PREROUTING 1 -p udp --dport 51413 -j MARK --set-mark 100
iptables -t mangle -I PREROUTING 1 -p tcp --dport 51413 -j MARK --set-mark 100
iptables -t mangle -I PREROUTING 1 -p tcp --sport 51413 -j MARK --set-mark 100
iptables -t mangle -I PREROUTING 1 -p udp --sport 51413 -j MARK --set-mark 100
# 51413 is torrent port
# end

So how do I know if it's working? I dont know. It shows no activity in the Graphs but the torrent download speed started to fluctuate a lot after adding these so maybe it is working. But it shows that data is being passed in the firewall MANGLE table in PREROUTING section.

15

The above seems interesting, but I wouldn’t trust the speed fluctuating.
Does your VPN provider have a usage meter? You could check that!

I found a bug in the current version of OPBR that I am using- it doesn’t create any ip tables rules for UDP ports.

I am going to upgrade and test before checking out what you wrote.

16

http://www.microhowto.info/troubleshooting/troubleshooting_the_routing_table.html#idp33040

17

So the issue as I suspected was the OPBR version I had.

If you update to the latest version, you can create a rule for the TCP/UDP port you use for torrenting, and it will create it properly (TCP+UDP) and route traffic originating from the router through tun interfaces.

The realtime graphs 100% confirms the above now! also no need for scripts that bind transmission to any VPN local IP. the above works with transmission bind_ip set to the router IP.

Thanks for your help all!

18

What rule did you create in OPBR? Can you post you OPBR config?

19

Sorry, what I said earlier wasn’t 100%. For some odd reason, Transmission used other ports as well as the one I specified to make the transfers. So the traffic was split between the tunnel and eth0.

I now settled on a solution that finally seems like redirects all traffic from Transmission to the tunnel.

First, here is my OpenVPN configurations:

config openvpn 'torrentVPN'                                                                                                             
        option dev 'tun1'                                                                                                          
        option nobind '1'                                                                                                          
        option verb '3'                                                                                                            
        option engine 'cryptodev'                                                                                                  
        option tun_mtu '1500'                                                                                                      
        option keepalive '10 60'                                                                                                   
        option persist_key '1'                                                                                                     
        option client '1'                                                                                                          
        option proto 'udp'                                                                                                         
        option resolv_retry 'infinite'                                                                                             
        option tls_client '1'                                                                                                      
        option auth_nocache '1'                                                                                                    
        option route_metric '50'                                                                                                   
        option cipher 'AES-256-CBC'                                                                                                
        option port '1194'                                                                                                         
        option persist_tun '1'                                                                                                     
        option auth_user_pass '/etc/openvpn/windscribeuserpass'                                                                    
        list remote 'uk-008.windscribe.com'                                                                                        
        option auth 'SHA512'                                                                                                       
        option ca '/etc/luci-uploads/windscribe_4096.crt'                                                                          
        option remote_cert_tls 'server'                                                                                            
        option key_direction '1'                                                                                                   
        option tls_auth '/etc/luci-uploads/windscribe_4096.key'                                                                    
        option reneg_sec '432000'                                                                                                  
        option enabled '1'                                                                                                         
        option route_noexec '1'                                                                                                    
        option compress 'lzo'                                                                                                      
        option route_delay '5'                                                                                                     
        option script_security '2'                                                                                                 
        option route_up '/etc/openvpn/updatebindaddress'

With these configurations, /etc/openvpn/updatebindaddress updates the bind_ipv4_address for transmission to be in the range of the VPN local subnet.

Here is the content of the updatebindaddress script (adapted from the post linked by @vgaetera, which won’t work for Openwrt because of the different strings used in the configuration files):

#!/bin/sh                                                                                                                          
                                                                                                                                   
/etc/init.d/transmission stop                                                                                                      
                                                                                                                                   
VPNADDR=`ifconfig | grep -A 5 "tun1" | grep "inet addr:" | cut -d: -f2 | awk '{ print $1}'`                                        
if [ -z "$VPNADDR" ]; then                                                                                                         
        VPNADDR=127.0.0.1                                                                                                          
fi                                                                                                                                 
                                                                                                                                   
cat /etc/config/transmission | sed "s/.*bind_address_ipv4.*/ \toption bind_address_ipv4 \'$VPNADDR\' /g" > /etc/config/transmission
                                                                                                                                   
chmod 666 /etc/config/transmission_test                                                                                            
                                                                                                                                   
mv /etc/config/transmission_test /etc/config/transmission                                                                          
                                                                                                                                   
/etc/init.d/transmission start

If you’re going to use the script above, make sure to change tun1 to whatever the name of your tunnel interface.

Now the issue that I was having, was that the version of OBPR I was running didn’t create any UDP port rules (even when appropriate settings were selected, i.e. UDP support in advanced configurations section).

So with the latest OBPR, here is the rule that worked:

config policy                                                                                                                      
        option comment 'P2P'                                                                                                       
        option interface 'torrentVPN'                                                                                                   
        option proto 'tcp udp'                                                                                                     
        option local_address '10.0.0.0/8'                                                                                          
        option local_port '1-65535'                                                                                                
        option chain 'OUTPUT'

So traffic originating from the router, with address range 10.0.0.0/8, will go through the tunnel. Checking the realtime graphs section shows a 1:1 image of the speed I see in transmission.

Hope this helps! This issue is solved now, so if there is any way to mark this thread as solved, let me know :slightly_smiling_face:

As always, many many thanks to @stangri for the amazing OPBR package!

6 Likes
20

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.