Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Proxy/VPN torrent
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Proxy/VPN torrent

MuZoMuZo Member

I would like to run my torrent client behind a proxy / VPN set up on another server of mine.

I'm using Deluge on Debian as torrent client and I've already tried to use the SOCKS proxy by SSHing to the other server but it partially works:

  • With Deluge 1.3.3 / python-libtorrent 0.15.10 / Debian Wheezy: UDP doesn't work at all, so if torrent trackers are only UDP it will never start.
  • With Deluge 1.3.6 / python-libtorrent 0.16.17 / Debian Sid: UDP works and if I check the announced IP with http://ipleak.net I see the proxy IP. However the IPv6 address is the real one and once the torrent is started the normal IPv4 is used to send data between peers.

Since torrent clients and proxies doesn't seems to go well together I would like to use a VPN but it should be applied only on the torrent client and not to all the server traffic.

I've read that it's possible with iptables to forward all traffic of a specific user to OpenVPN but I have no idea how to do it.

The other solution could be to run them in a OpenVZ container where the VPN get applied globally, but I'm not sure how should the NAT on the host configured as the traffic should go trough the VPN.

Comments

  • Hi,
    it's definitely possible with iptables.

    I used the following setup to proxy all traffic from the user "yacy" through a VPN on 10.10.0.0/24.

    #Redirect yacy through VPN
    /sbin/ip rule add fwmark 1 table 1
    /sbin/ip route add default via 10.10.0.10 dev tun1 table 1
    /sbin/sysctl -w net.ipv4.conf.tun1.rp_filter=2
    $IPTABLES -t mangle -A OUTPUT -m owner --uid-owner yacy -o $INT -j MARK --set-mark 1
    $IPTABLES -t nat -A POSTROUTING -o tun1 -m owner --uid-owner yacy -j SNAT --to-source 10.10.0.10
    

    Some explanations:

    • OpenVPN-client uses tun1 and has the IP 10.10.0.10
    • OpenVPN does not push a default route
    • All outgoing traffic proxied for user yacy
    • $INT is the primary NIC (e.h. eth0)
    • $IPTABLES is /sbin/iptables

    Note: You may want to run the same iptables-rules for IPv6.

    If someone else has a better solution, please let me know :)

    The best,

    gehaxelt

    Thanked by 1MuZo
  • make a virtualbox , setup vpn

  • infected said: make a virtualbox , setup vpn

    Oh, please no. We hackers are too lazy for that. :P

    said: I've read that it's possible with iptables to forward all traffic of a specific user to OpenVPN but I have no idea how to do it.

    http://unix.stackexchange.com/questions/66203/how-do-i-route-traffic-through-specific-interface-for-a-specific-process

    http://unix.stackexchange.com/questions/28571/redirect-traffic-through-vpn-on-an-as-needed-basis

    Might give more insight to @gehaxelt's suggestion. Hopefully you are running deluge under a dedicated and restricted user. And you also need to make sure that OpenVPN is not pushing default gateways. :D

  • MuZoMuZo Member

    @gehaxelt awesome, thank you. I've used Nyr openvpn setup script, added "route-nopull" to the config file and ran your commands.

    I'm now trying to access the WebUI which runs on port 8112 but it doesn't work

    # client ifconfig
    tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255
    
    # vpn (redir cause I'm a iptables noob)
    redir --lport=8112 --laddr=X.X.X.X --cport=8112 --caddr=10.8.0.6
    

    If I try to ping/traceroute 10.8.0.6 it doesn't work either.

    About IPv6 I'm not sure if OpenVPN supports it, the test VPS I'm using doesn't have IPv6 so I can't test it now.

    I've found this snipped on deluge forums (which assume a configured port set):

    ip6tables -A INPUT -p tcp -m multiport --dports 12021:12029 -j DROP -m comment --comment
     "Torrents TCPv6"
    ip6tables -A INPUT -p udp -m multiport --dports 12021:12029 -j DROP -m comment --comment
     "Torrents UDPv6"
    ip6tables -A OUTPUT -m owner --uid-owner 5003 -d 0::0/0 -j REJECT
    

    But with the VPN wouldn't the incoming UDP packets get blocked anyway if no forwarding is set-up?

  • Hi,
    well there are a lot of things that can fail/make the ping/traceroute inoperable.

    I assume that OpenVPN establishes the connection without problems?

    Not sure if I can help you. Maybe you could provide some more information:

    On the VPN host:

    • What's the OpenVPN host address (virtual)?

    On the VPN client:

    • What's the OpenVPN client address + interface?
    • What is the ouput of:

      • sudo iptables -L -vn
      • sudo iptables -L -vn -t nat
      • sudo iptables -L -vn -t mangle
      • sudo route -n
      • sudo ip rule show
      • sudo netstat -tulpen
      • sudo ip route show
      • sysctl net.ipv4.conf.tun0.rp_filter
    • As which user are you trying to ping the VPN host? Did you adjust the iptable-statements correctly?

    The best,
    gehaxelt

  • MuZoMuZo Member

    Yes the setup works fine. It connects correctly to OpenVPN and traffic from the specified user go trough the VPN.

    Host (VPN server)

    tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
    

    Client

    # connection
    openvpn --script-security 2 --config client.conf
    
    # ifconfig
    tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255
    
    # commands
    /sbin/ip rule add fwmark 1 table 1
    /sbin/ip route add default via 10.8.0.6 dev tun0 table 1
    /sbin/sysctl -w net.ipv4.conf.tun0.rp_filter=2
    /sbin/iptables -t mangle -A OUTPUT -m owner --uid-owner deluge -o eth0 -j MARK --set-mark 1
    /sbin/iptables -t nat -A POSTROUTING -o tun0 -m owner --uid-owner deluge -j SNAT --to-source 10.8.0.6
    



    What I'm trying to do now is to forward port 8112 to the client, but when I try to ping/traceroute the client IP (10.8.0.6) from the host it can't connect.

  • MuZoMuZo Member

    From client to server

    traceroute to 10.8.0.1 (10.8.0.1), 30 hops max, 60 byte packets
     1  10.8.0.1 (10.8.0.1)  44.915 ms  44.935 ms  44.933 ms
    

    From server to client

    traceroute to 10.8.0.6 (10.8.0.6), 30 hops max, 60 byte packets
     1  * * *
     2  * * *
     3  * * *
     4  * * *
     5  * * *
     6  *^C
    
  • Hmm, that's strange.

    Are there any iptable-restrictions on the client?

  • MuZoMuZo Member

    There shouldn't be any

    iptables -F
    
    iptables -L
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination
    
    Chain fail2ban-ssh (0 references)
    target     prot opt source               destination
    

    If I ping/traceroute the public IPv4 of the client it works

  • MuZoMuZo Member

    If it can help:

    Host (OpenVZ VPS)

    route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
    10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
    0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 venet0
    

    Client (VMware VPS)

    route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    0.0.0.0         Y.Y.10.129   0.0.0.0         UG    0      0        0 eth0
    10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
    Y.Y.10.128   0.0.0.0         255.255.255.128 U     0      0        0 eth0
    
Sign In or Register to comment.