Using VPN Director to route only torrent traffic through VPN

[goldnet]

Hello,

My goal is to have ONLY qBittorent traffic directed through a VPN using RT-AX88U Pro.

All the pieces seem to be in place but none of the torrent traffic is going to the VPN.

Here's the set it up:

qBittorent bound to OpenVPN Client on PC <-> OpenVPN Server on Router <-> VPN Director <-> Wireguard client on Router <-> VPN provider

qBittorent is bound to the OpenVPN client interface connecting to an OpenVPN server on the router.
The VPN provider connection is done with Wireguard client on the router.
The VPN Director directs the traffic from the OpenVPN client

NOTE: The only reason I am using a combination of OpenVPN and Wireguard is that it seemed more obvious how to OpenVPN server than the Wireguard server and more obvious how to set up the Wireguard client than the OpenVPN client. I can switch to using either OpenVPN or Wireguard for everything.

This is the config that the router generates for the OpenVPN client that qBittorent binds to on the PC:

# Config generated by Asuswrt-Merlin 388.8, requires OpenVPN 2.4.0 or newer.
    client
    dev tun
    pull-filter ignore "redirect-gateway" # manually added
    route 172.16.0.0 255.240.0.0 vpn_gateway # manually added
    proto udp
    remote 76.169.XXX.XXX 1194
    resolv-retry infinite
    nobind
    float
    ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:CHACHA20-POLY1305
    cipher none # manually added
    auth none # manually added
    data-ciphers none # manually added
    keepalive 15 60
    remote-cert-tls server

This seems like it ought to work but the torrent traffic doesn't go to the VPN. Also, 76.169.XXX.XXX is my WAN IP from my ISP. It is not a static IP so it seems like it shouldn't really be in here but that's how it was when the router exported the config file.

I greatly appreciate if you can share how to get it working.

 

[eibgrad]

There are so many issues here, I'm not sure where to begin.

I thought based on the other thread you had this working already w/ Merlin?

redirecting VPN Server to VPN Fusion client

I'd like to route all traffic from an OpenVPN server client to the Wireguard client. All the traffic keeps from the OpenVPN server keeps going to the internet instead of through the Wireguard client though. I greatly appreciate any insight into what's missing or incorrect here.

www.snbforums.com

If that's the case, and what you've presented NOW is your attempt to fine tune it, that's an important detail to establish in this new thread. Because any subsequent failure would presumably be due to your customization.

It would be helpful to know how you configured the "Client will use VPN to access" setting on the OpenVPN server (LAN Only, Internet Only or Both). That has a direct impact on how the client config file, as originally generated, was configured prior to your changes. You also changed the tunnel's IP network in the client config file to a netmask of 255.240.0.0 from what is supposed to be 255.255.0.0 on the server (NOT a good idea). And then you made a bunch of other manual changes.

To make matters worse, that 172.16.0.0/16 network doesn't need a route directive. That's the tunnel's IP network! You use route directive(s) like static routes, to direct specific *destination* IPs over the tunnel (or WAN if you prefer), NOT source IPs.

What I think is really at the core of your problems here is a misunderstanding about what that 172.16.0.0./255.255.0.0 network is all about.

As I said, that's the tunnel's IP network. It's only needed as a means to route between the client's local IP network (e.g., 192.168.1.x) and the server's local IP network (e.g., 192.168.2.x). That's why you don't typically need such a large network for the tunnel. Something like /24 (iirc, the default) is plenty (and even that is overkill in most cases).

I get the sense you think the tunnel's IP and that of the client are the same, or perhaps you're trying to make the client's local IP network a subnet of the tunnel's IP network. That's NOT correct. All three IP networks in a routed OpenVPN configuration need to be unique and non-overlapping, as I described above.

Before you start making customizations of any kind, you need to get the OpenVPN configuration working properly. Forget about all this customization for the time being. Those are only obscuring the real problems w/ the config.

BTW, it also would help to see the actual OpenVPN server config file, and the originally generated client config file before you changed it.

cat /tmp/etc/openvpn/server1/config.ovpn

 

[eibgrad]

Oh, and something else as well.

That OpenVPN client is a PC, right? I assume the torrent app is running on that PC.

If it's your intent to limit what uses the tunnel to that of the torrent app, you're NOT going to be able to do it without PBR (policy based routing) on the client.

As configured, the client has no means to route only a specific app across the tunnel. All you can do on the client is control what destination IPs are routed over the tunnel. In order to be selective, the client (PC) would not only need to implement its own PBR, but one that was able to specifically target the ports used by the app. The only way to do it without PBR would be to route (using route directives) the destination IPs known to be used by the torrent app. Of course, that itself can be problematic because you often don't know what those destination IPs will be. As a result, you may be required to route everything, if only to make sure nothing escapes through the local default gateway.

This gets us right back to this issue of source and destination IPs when it comes to routing over the tunnel. That's what's causing so much of your problems here. You're failing to make this important distinction. And until you do, it's going to be very difficult to accomplish your goals.

P.S. This is NOT easy stuff. Everybody gets confused when it comes to networking, myself included. It's just inherently difficult, and often NOT intuitive. And so don't become discouraged.

 

[cptnoblivious]

The real issue is that accomplishing this based on a client application is very difficult.

Doing this based on IP address is much more straight forward.

What I do is to run a separate VM for torrents. That VM has it's own IP on the LAN (i.e. the NIC is 'bridged'). And then for that IP routing becomes straightforward.

Some considerations of going with the setup you diagrammed in your original post:
1. How will you know of failures, i.e. when something on the VPN side goes down?
2. Will the system fail 'open' or 'closed', i.e. will traffic be routed even if a VPN isn't available? If not, how and where will you implement a killswitch.
3. Is there a negative impact if the system fails and traffic is exposed outside the VPN? Since we're talking torrents over VPN, I'm assuming Yes. In that case, a simple straightforward setup will be much easier to maintain and secure. Complexity is the enemy of well functioning and reliable systems.

Just my $0.02

 

[eibgrad]

The real issue is that accomplishing this based on a client application is very difficult.

Doing this based on IP address is much more straight forward.

What I do is to run a separate VM for torrents. That VM has it's own IP on the LAN (i.e. the NIC is 'bridged'). And then for that IP routing becomes straightforward.

In principle, I agree.

However, in this particular case, if the PC is the one managing the OpenVPN client and the torrent app, it's NOT the fact the guest VM has its own LAN ip that makes the difference (that's only incidental).

I assume there is NO policy based routing on that PC in order for that to matter. Although the OP could benefit from a guest VM, it's because the guest VM would not only be supporting the torrent app, but the OpenVPN client too. The assumption being that the guest VM would only exist for the benefit of the torrent app, so it's fine that ALL of the guest VM is routed over the VPN. Meanwhile, the host remains bound to the local WAN/ISP.

I'm only being uber precise here because it's important for the OP to understand that the VM solution you've described assumes the OpenVPN client is moved from the host to the guest VM. That may not be obvious at first blush.

The difference in IP between the host and guest VM *would* be of significance if, for example, the OpenVPN client was being hosted by the upstream router, and it was capable of source-based routing for the LAN devices behind it. NOW that upstream router can discriminate between the host and guest VM based on their respective IPs.

 

[goldnet]

Oh, and something else as well.

That OpenVPN client is a PC, right? I assume the torrent app is running on that PC.

If it's your intent to limit what uses the tunnel to that of the torrent app, you're NOT going to be able to do it without PBR (policy based routing) on the client.

As configured, the client has no means to route only a specific app across the tunnel. All you can do on the client is control what destination IPs are routed over the tunnel. In order to be selective, the client (PC) would not only need to implement its own PBR, but one that was able to specifically target the ports used by the app. The only way to do it without PBR would be to route (using route directives) the destination IPs known to be used by the torrent app. Of course, that itself can be problematic because you often don't know what those destination IPs will be. As a result, you may be required to route everything, if only to make sure nothing escapes through the local default gateway.

This gets us right back to this issue of source and destination IPs when it comes to routing over the tunnel. That's what's causing so much of your problems here. You're failing to make this important distinction. And until you do, it's going to be very difficult to accomplish your goals.

P.S. This is NOT easy stuff. Everybody gets confused when it comes to networking, myself included. It's just inherently difficult, and often NOT intuitive. And so don't become discouraged.

Thank you very much for all the misunderstandings you pointed out.

Regarding other thread you mentioned: Yes, I said I had it working with VPN director and the firmware was unstable. Specifically this is what happened: I added this line to the OpenVPN client config (in addition to the other manually added lines): "route 128.0.0.0 128.0.0.0 vpn_gateway" and that made everything seem to work fine. Then apparently there were some ISP issues and I had techs come out 3 times troubleshooting. What I thought was a merlin firmware bug now seems likely to have been an ISP service issue. After dealing with the ISP side of things, I realized that although "route 128.0.0.0 128.0.0.0 vpn_gateway" made the torrent traffic route through the VPN, some of the regular PC traffic was also routing through the VPN in a seemingly random way.

Regarding "Client will use VPN to access", it is set to "Both".

Regarding "/tmp/etc/openvpn/server1/config.ovpn", this is the file on the router:

daemon ovpn-server1
topology subnet
server 172.16.0.0 255.255.0.0
proto udp4
multihome
fast-io
port 1194
dev tun21
txqueuelen 1000
data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:CHACHA20-POLY1305
data-ciphers-fallback AES-128-CBC
keepalive 15 60
verb 3
push "route 10.0.0.0 255.255.0.0 vpn_gateway 500"
duplicate-cn
push "redirect-gateway def1"
ca ca.crt
dh dh.pem
cert server.crt
key server.key
script-security 2
up 'ovpn-up 1 server'
down 'ovpn-down 1 server'
status-version 2
status status 5

# Custom Configuration
cipher none
auth none
data-ciphers none

As you suggested, the OpenVPN client and server should work first without config file changes. I just did exactly that:

I removed the routing modifications from the OpenVPN client config file.

I have qBittorent bound to 172.16.0.2 on the PC's "OpenVPN TAP-Windows6" adapter.

My understanding is that I don't need policy based routing on the PC because qBittorent can bind to the OpenVPN PC client adapter.

Everything seems to work perfectly before making changes to the OpenVPN client config file.

Assuming you concur that everything is OK to this point, 2 more things are needed:

1. Make traffic on the PC default to go through the ethernet adapter instead of the OpenVPN adapter. IOW, modify the OpenVPN client config file to do split-tunneling so that only torrent traffic is going through the OpenVPN client because it is bound to that adapter but everything else goes to the ethernet adapter. Is it correct that I can configure this split-tunneling by modifying the OpenVPN client config file?
2. Direct traffic from the OpenVPN server on the router to the WireGuard client on the router. I thought this could be accomplished with VPN director. Based on your clarifications, I am thinking I need to do this policy based routing with iptables instead. Is that correct?

 

[eibgrad]

route 128.0.0.0 128.0.0.0 vpn_gateway

Regarding the above…

Using route directives (i.e., static routing) will work provided you KNOW all the destination IPs the torrent app will be using. In theory, you could ignore (filter out) the redirect-gateway directive and add route directives (w/ the vpn_gateway option, although since that's the default, it could be left off the directive) to the OpenVPN client config, and only those destination IPs would be routed over the tunnel. But that's problematic when the app is unlikely to know the destination IPs ahead of time. So instead you're attempting to control what uses the VPN based on source IP or the specific app (by binding the torrent app to the VPN directly). And that's when it all falls apart because you do NOT have such capability on the PC. That requires PBR. All you have at your disposal is static routing in the form of route directives.

That's why @cptnoblivious made the suggestion that he did. By placing the OpenVPN client and torrent app on its own guest VM, that creates a *crude* form of PBR, where traffic *sourced* from the host uses the WAN/ISP, while traffic *sourced* from the guest VM uses the VPN. Problem solved!

Granted, having to install and manage a VM solely for this purpose is more than most ppl want to deal with. But you do NOT presently have the luxury of using traditional PBR. Not unless you can dig up something for the PC platform (I assume this is Windows). I don't use Windows, but there may in fact be some clever means to bind only a specific app to the OpenVPN client. I'm just NOT aware of it. And if it exists, I presume it's less than straight-forward.

I did find the following, but I have no clue if it actually works.

How do I implement per-app routing behavior on windows?

I am running a VPN in windows 10 desktop (using OpenVPN) and the VPN is the default gateway, so that all traffic by default goes through the VPN tunnel. However, I would like to exempt certain app...

stackoverflow.com

 

[goldnet]

route 128.0.0.0 128.0.0.0 vpn_gateway

Regarding the above…

Using route directives (i.e., static routing) will work provided you KNOW all the destination IPs the torrent app will be using. In theory, you could ignore (filter out) the redirect-gateway directive and add route directives (w/ the vpn_gateway option, although since that's the default, it could be left off the directive) to the OpenVPN client config, and only those destination IPs would be routed over the tunnel. But that's problematic when the app is unlikely to know the destination IPs ahead of time. So instead you're attempting to control what uses the VPN based on source IP or the specific app (by binding the torrent app to the VPN directly). And that's when it all falls apart because you do NOT have such capability on the PC. That requires PBR. All you have at your disposal is static routing in the form of route directives.

That's why @cptnoblivious made the suggestion that he did. By placing the OpenVPN client and torrent app on its own guest VM, that creates a *crude* form of PBR, where traffic *sourced* from the host uses the WAN/ISP, while traffic *sourced* from the guest VM uses the VPN. Problem solved!

Granted, having to install and manage a VM solely for this purpose is more than most ppl want to deal with. But you do NOT presently have the luxury of using traditional PBR. Not unless you can dig up something for the PC platform (I assume this is Windows). I don't use Windows, but there may in fact be some clever means to bind only a specific app to the OpenVPN client. I'm just NOT aware of it. And if it exists, I presume it's less than straight-forward.

I did find the following, but I have no clue if it actually works.

How do I implement per-app routing behavior on windows?

I am running a VPN in windows 10 desktop (using OpenVPN) and the VPN is the default gateway, so that all traffic by default goes through the VPN tunnel. However, I would like to exempt certain app...

stackoverflow.com

OK let's assume the torrent process is in a VM or is being forced through the VPN by that special windows command in the link you included at the end (thank you very much for finding that obscure feature!).

I still want to offload the encryption processing onto the router.

The next step is for the traffic from the OpenVPN server on the router be directed to the WireGuard Client on the router. My understanding is that this isn't possible with VPN Director. Should these commands in the firewall-start script work?

# Allow traffic from OpenVPN to WireGuard
iptables -A FORWARD -i tun21 -o wgc1 -j ACCEPT
iptables -A FORWARD -i wgc1 -o tun21 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Masquerade (NAT) traffic going out of the WireGuard interface
iptables -t nat -A POSTROUTING -o wgc1 -j MASQUERADE

 

[eibgrad]

OK let's assume the torrent process is in a VM or is being forced through the VPN by that special windows command in the link you included at the end (thank you very much for finding that obscure feature!).

I still want to offload the encryption processing onto the router.

The next step is for the traffic from the OpenVPN server on the router be directed to the WireGuard Client on the router. My understanding is that this isn't possible with VPN Director. Should these commands in the firewall-start script work?

# Allow traffic from OpenVPN to WireGuard
iptables -A FORWARD -i tun21 -o wgc1 -j ACCEPT
iptables -A FORWARD -i wgc1 -o tun21 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Masquerade (NAT) traffic going out of the WireGuard interface
iptables -t nat -A POSTROUTING -o wgc1 -j MASQUERADE

As I said originally, I don't use WG, so I'm not 100% sure whether the router supports WG w/ the VPN Director. I suspect it does. And if it does, you should be able to specify the IP network of the OpenVPN server's tunnel as a *source* IP that should be directed over the WG connection. And since the only thing being routed from the OpenVPN client is that of the torrent app (due to the fact it's on its own VM), you can safely assume anything in the tunnel is only that of the torrent app.

Now if it turns out the VPN Director can NOT manage PBR for WG, then you're stuck once again w/ the same old problem. How to force *only* the traffic coming from the OpenVPN server's tunnel through the WG client. Messing w/ the firewall will NOT help because that's only determining what's ALLOWED/DENIED in terms of forwarding from one network interface to another. But that does NOT actually *cause* the traffic to move from one network interface to another. That is only determined by the routing system (and based on destination IP, or the source IP provided you have access to PBR).

As you can see, we just keep returning to the same old problems. You keep trying to circumvent the fact you don't have access to PBR, whether that's on the PC, or the remote router. The suggestion to use a VM on the PC happens to be viable. As I said, it's a *very* crude form of PBR. But at least it should work. But once you reach the remote router, you're right back to needing PBR. Only good thing I can say in that regard is that the Merlin firmware at least makes it plausible (if not necessarily easy) to implement your own PBR should that prove necessary. But I was hoping that the VPN Director would work w/ WG.

 

[goldnet]

As I said originally, I don't use WG, so I'm not 100% sure whether the router supports WG w/ the VPN Director. I suspect it does. And if it does, you should be able to specify the IP network of the OpenVPN server's tunnel as a *source* IP that should be directed over the WG connection. And since the only thing being routed from the OpenVPN client is that of the torrent app (due to the fact it's on its own VM), you can safely assume anything in the tunnel is only that of the torrent app.

Now if it turns out the VPN Director can NOT manage PBR for WG, then you're stuck once again w/ the same old problem. How to force *only* the traffic coming from the OpenVPN server's tunnel through the WG client. Messing w/ the firewall will NOT help because that's only determining what's ALLOWED/DENIED in terms of forwarding from one network interface to another. But that does NOT actually *cause* the traffic to move from one network interface to another. That is only determined by the routing system (and based on destination IP, or the source IP provided you have access to PBR).

As you can see, we just keep returning to the same old problems. You keep trying to circumvent the fact you don't have access to PBR, whether that's on the PC, or the remote router. The suggestion to use a VM on the PC happens to be viable. As I said, it's a *very* crude form of PBR. But at least it should work. But once you reach the remote router, you're right back to needing PBR. Only good thing I can say in that regard is that the Merlin firmware at least makes it plausible (if not necessarily easy) to implement your own PBR should that prove necessary. But I was hoping that the VPN Director would work w/ WG.

Thank you very much for all your thoughts on this.

For the time being I just added a second physical NIC and bound qBittorrent to that adapter. VPN director directs all traffic from the IP of that second physical NIC to the WG client. The second physical NIC used by qBittorrent has a high metric value so other traffic on the PC does not default to there.

It has worked fine without adding the additional drain on system resources and extra fiddling from running a VM.

It seems that I ought to be able to use a virtual NIC instead of a physical NIC but I don't that working yet. Maybe SoftEther is the right thing for this.

Once I get it working with a virtual NIC, it seems like it would be a small step to get it working with an VPN client because the VPN client literally functions through a virtual NIC. Unless there is a distinction between a non-VPN virtual NIC and the virtual NIC that a VPN client creates, it seems a VPN client on the PC ought to work as well.