What's new

Deluge and OpenVPN

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

krl69

New Around Here
Just got me a gt-ax11000 and installed the latest merling firmware.

Installed Deluge for torrents. Deluge supports Socks5 but I want to use OpenVPN due to speed. Have set up OpenVPN and it works great, but I want to run everything on VPN but with exceptions. Therefore I use VPN Director and it works on devices on the LAN, but Deluge continues to run outside the VPN even though it is not set as an exception. If I drop VPN Director and choose that everything (Redirect Internet traffic through tunnel = Yes (ALL) under OpenVPN settings) should be run via VPN then Deluge also runs via VPN. I have set up in VPN Director the following way: Local IP = 192.168.50.0 / 24 against OVPN1 which is everything on the LAN and all devices on the LAN run via VPN as it should. So e.g. Local IP = 192.168.50.80 against WAN running outside VPN. But Deluge also runs outside even though directly on the router and one would think that it uses the router's IP and which should be intercepted by the VPN Director, but it does not.
 
Whenever you use the VPN Director, this takes the router itself OFF the VPN! That's just a side-effect of how it's implemented. Therefore, any router-based processes and services will always be routed over the WAN, whether you include the router's LAN ip explicitly (e.g., 192.168.50.1) or implicitly (e.g., 192.168.50.0/24) in routing policy.

That might seem strange at first glance since other LAN devices can be selectively routed over the VPN w/o issue. But the router is different from other LAN devices in that it is *hosting* the internet connection(s) (e.g., WAN and VPN). As such, it normally accesses the internet via those network interfaces directly (public IP from the ISP, or assigned IP on the VPN, respectively), and NOT the LAN interface (192.168.50.1). So routing policy rules based on 192.168.50.1 normally have no effect. They only have effect *if* the router is specifically bound to its LAN network interface for a given service. But in most instances, its services are bound to ALL network interfaces (0.0.0.0) within their respective configuration files.

That last statement is the key to having something like Deluge, Transmission, etc., routed over the VPN. You need to configure the service so it's bound *only* to the LAN network interface rather than ALL network interfaces. NOW a routing policy that includes 192.168.50.1 will be honored. Or in some cases, you might want to multihome the LAN interface w/ a new IP network (e.g., 192.168.51.1/32) and configure the service and routing policy to use it. That can be useful if you only want to force that one service over the VPN and not something else that happens to be bound to the router's LAN network interface (e.g., the GUI).
 
Last edited:
That last statement is the key to having something like Deluge, Transmission, etc., routed over the VPN. You need to configure the service so it's bound *only* to the LAN network interface rather than ALL network interfaces. NOW a routing policy that includes 192.168.50.1 will be honored. Or in some cases, you might want to multihome the LAN interface w/ a new IP network (e.g., 192.168.51.1/32) and configure the service and routing policy to use it. That can be useful if you only want to force that one service over the VPN and not something else that happens to be bound to the router's LAN network interface (e.g., the GUI).
Thanks for the thorough answer! I'm on unknown terrain here. I simply do not know how to connect a service running directly on the router to a specific IP. Do you have any examples of how this can be done? I have created a bridge interface br0 from the LAN-interface 192.168.50.1 and gave it the IP 192.168.50.2. But I dont know how to connect/dedicate it to the Deluge service. And I dont know if thats the right approach.
 
You can multi-home the LAN network interface using an init-start script.

Code:
SCRIPTS_DIR='/jffs/scripts'
SCRIPT="$SCRIPTS_DIR/init-start"

mkdir -p $SCRIPTS_DIR

create_script() {
cat << 'EOF' > $SCRIPT
#!/bin/sh
(
until ifconfig br0 &>/dev/null; do sleep 5; done
ifconfig br0:1 192.168.99.1 netmask 255.255.255.255
) &
EOF
chmod +x $SCRIPT
}

if [ -f $SCRIPT ]; then
    echo "error: $SCRIPT already exists; requires manual installation"
else
    create_script
    echo 'Done.'
fi
:

Enable JFFS scripts in Administration > System and copy/paste the above script into the terminal window of an SSH session. It will create and install the necessary init-start script.

Now find the config file for deluge and locate the setting that controls how it binds itself to local network interfaces. I don't use deluge myself, so I can't tell you specifically what that is, but most services usually have such a setting set to 0.0.0.0. Change it to 192.168.99.1.

Finally, add a routing policy rule using 192.168.99.1 as the local-ip and bound to the VPN, and reboot.
 
You can multi-home the LAN network interface using an init-start script.

Code:
SCRIPTS_DIR='/jffs/scripts'
SCRIPT="$SCRIPTS_DIR/init-start"

mkdir -p $SCRIPTS_DIR

create_script() {
cat << 'EOF' > $SCRIPT
#!/bin/sh
(
until ifconfig br0 &>/dev/null; do sleep 5; done
ifconfig br0:1 192.168.99.1 netmask 255.255.255.255
) &
EOF
chmod +x $SCRIPT
}

if [ -f $SCRIPT ]; then
    echo "error: $SCRIPT already exists; requires manual installation"
else
    create_script
    echo 'Done.'
fi
:

Enable JFFS scripts in Administration > System and copy/paste the above script into the terminal window of an SSH session. It will create and install the necessary init-start script.

Now find the config file for deluge and locate the setting that controls how it binds itself to local network interfaces. I don't use deluge myself, so I can't tell you specifically what that is, but most services usually have such a setting set to 0.0.0.0. Change it to 192.168.99.1.

Finally, add a routing policy rule using 192.168.99.1 as the local-ip and bound to the VPN, and reboot.
Thank you very much, now it works! But had to switch to Transmission as Deluge does not have the ability to bind to a specific IP address. What I am now struggling with is to open port "51413" which Transmission uses. I have run the recipe to open in the firewall but now this goes via VPN so I think there are other places I have to look for.
 
Thank you very much, now it works! But had to switch to Transmission as Deluge does not have the ability to bind to a specific IP address. What I am now struggling with is to open port "51413" which Transmission uses. I have run the recipe to open in the firewall but now this goes via VPN so I think there are other places I have to look for.

You probably now have a secondary issue when it comes to the listening port for remote clients. Those are going to be bound to the VPN too. And that requires your VPN provider support port forwarding over his end of the tunnel (some do, but most do NOT).
 
You probably now have a secondary issue when it comes to the listening port for remote clients. Those are going to be bound to the VPN too. And that requires your VPN provider support port forwarding over his end of the tunnel (some do, but most do NOT).
It was something I thought too. Tried this procedure: Port forwarding in AsusWRT Merlin | OVPN.com and run this in SSH: iptables -t nat -A PREROUTING -i tun+ -p udp --dport 51413 -j DNAT --to-destination 192.168.99.1 and one with tcp. But no luck.
 
Most any VPN provider that offers port forwarding will make it known in their FAQ and provide specific instructions, which requires port forwarding on their end of the tunnel too (usually via some web page on their website), since typically many users are using the same servers. IOW, if you need port forwarding over the VPN, you have to take this into consideration before committing to a VPN provider.

AirVPN is a good example of how it's typically supported.


Mullvad also supports port forwarding.


But these are the exceptions. Most VPN providers do NOT offer this capability.
 
PIA is one of the worst imo. Too many restrictions. Last I tried it, it worked on a limited number of servers, you could only have *one* forwarded port, and (worst of all), you could only determine the port at *runtime* using their special API. And you had to take measures to keep that port open over time w/ some sort of keepalive. Just way too much trouble. Esp. when compared to the competitors.
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top