Setup VPN for WAN out only

Troubleshooting
21

Bring the VPN down, with dietpi-vpn (to clear the unwanted iptables rules).

Check then your rules, we want eth0 as default gateway and the kill-switch for transmission should also be still there , but I’m not sure if dietpi-vpn will also erase it when the interface goes down.
Just check if the rule is still there, if not add it again.

Then you can bring up the tunnel with openvpn

sudo openvpn --config /path/to/vpn_config.opvn

I had also a look into transmission and you can directly specify an IP address where it should bind to. So no more hassle with iptable rules :sweat_smile:

In /etc/transmission-daemon/settings.json is an option bind-address-ipv4 where you can just put in the IP of the tunnel interface. (Check via ip a). I didn’t find a way to modify this via the web UI tho.

"bind-address-ipv4": "<VPN_IP_HERE>"

I hope this s**t is working now, it drives me mad too :sweat_smile:

22

I can’t get to the part of “trying” because it looks like the VPN as soon as it goes up, it will tunnel all traffic through it despite having the #redirect-gateway def1 commented in my openvpn config.

So first, I need to make sure the VPN isn’t tunneling anything until I explicitly tell it to tunnel (I suppose).

But I’m seeing you are getting a lot of work in helping me out with this, I may “give up” and search later on when I have some time for this. It has been quite a struggle, 1 week around this with no success.

23

Hmm, can you share your actual config file again? Or ask your VPN provider if they send some push options when the connections is established, which probably sets the tun0 as default route again.

You can prevent such behaviour withroute-nopull option. See https://unix.stackexchange.com/questions/16500/how-to-refuse-routes-that-are-pushed-by-openvpn-server

24 
client
remote REDACTED
dev tun
proto udp
auth-user-pass


resolv-retry infinite
#redirect-gateway def1
route 10.0.2.0 255.255.255.0 net_gateway
route 10.0.3.0 255.255.255.0 net_gateway
route 192.168.2.0 255.255.255.0 net_gateway
persist-key
persist-tun
nobind

data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

auth SHA256
ping 5
explicit-exit-notify 2
script-security 2
remote-cert-tls server
route-delay 5
verb 4

@Jappe his is the client out of the box (I mean, I added the routes for my VLANs to not be routed through the VPN, but other than that, the config is as shown here).

25

You can try to add the route-nopull option.
Maybe @trendy has another idea?!

26

Maybe it would be easier to setup a pbr rule to tell what will go through the wan first, then the rest will go through the VPN. I have done it in a similar way.

Add the default and some static routes in a custom table:

ip ro add default via 172.16.4.1 dev eth0 table 100

Then include rules for the traffic that will go through wan:

ip rule add not iif lo sport <transmission-port> to default lookup 100 prio 1000

So everything except traffic from transmission will go via wan.

You may use other descriptors, like source ip (in case it is predictable) or uid.

27

@trendy could you please guide me or where to put those? Sorry, at this point I’m afraid of doing it without being 100% sure because one time I locked myself from the SSH and my server is headless and sometimes I don’t even have physical access to it.

Also, with those rules, should I use the dietpi-vpn or no? And should I use it with the killswitch on? Should I use the no-pull or redirect-gateway def1 in the openvpn config?

Thank you all.

edit: I was trying to solve it myself and upon posting those 2 commands and your description on chatgpt it told me that the second command is saying that the traffic from transmission port is the one going through the WAN and not the opposite, but you said the opposite so now I am even more confused. I trust more on you than ChatGPT but just to make sure there is no mistakes.

I was trying to put this in the static-up rules from dietpi-vpn.

28

These are simple commands for the prompt. They are lost after a reboot. So you could do a shutdown -r +2 and it will reboot in 2 mins if you loose the connectivity.

29

Just ran those 2 commands directly (while dietpi-vpn was running with killswitch on) and the result was that I lost WAN on server but local network was still working.

I think you may have misunderstood the question: you are indeed forwarding transmission traffic to a specific (gateway IP) but I want to achieve is that I forward only transmission traffic to the tunnel created by dietpi-vpn and leave everything else just using the default wan. Problem is some kind of conflicts when dietpi-vpn starts that seems to mess with the tables.

30

Yes, I understood that correctly.

Add this and try again:

iptables -I OUTPUT -o eth0 -j ACCEPT

Or disable the killswitch, you are not using it anyway.

31

I think it worked. The thing is… how do I know which ports transmission use for outbound communications? I know that I may use a specific one for incoming (if I open the port which I don’t) so I’m limited to the outbound peers which I connect to and have random ports I believe.

Setting the WebUI port from transmission doesn’t make sense I believe.

Example, this is what happens when I have transmission running:

tcp   ESTAB      0      2525           10.16.4.131:56175        89.149.241.1:25136 users:(("transmission-da",pid=9842,fd=22))                                  
tcp   ESTAB      0      0              10.16.4.131:45364        172.67.72.98:443   users:(("transmission-da",pid=9842,fd=52))                                  
tcp   ESTAB      0      9              10.16.4.131:41119      85.242.144.182:65432 users:(("transmission-da",pid=9842,fd=56))                                  
tcp   ESTAB      0      0              10.16.4.131:45338        172.67.72.98:443   users:(("transmission-da",pid=9842,fd=48))                                  
tcp   ESTAB      0      3162           10.16.4.131:35407       94.185.80.230:58932 users:(("transmission-da",pid=9842,fd=37))                                  
tcp   ESTAB      0      9              10.16.4.131:33253       109.50.173.14:56516 users:(("transmission-da",pid=9842,fd=41))                                  
tcp   ESTAB      0      0              10.16.4.131:45300        172.67.72.98:443   users:(("transmission-da",pid=9842,fd=39))                                  
tcp   ESTAB      0      0              10.16.4.131:45268        172.67.72.98:443   users:(("transmission-da",pid=9842,fd=32))                                  
tcp   ESTAB      0      43             10.16.4.131:40839       85.241.129.90:1370  users:(("transmission-da",pid=9842,fd=47))                                  
tcp   ESTAB      0      35             10.16.4.131:36277      79.127.131.215:40727 users:(("transmission-da",pid=9842,fd=30))                                  
tcp   ESTAB      0      26             10.16.4.131:55647      158.173.152.51:48056 users:(("transmission-da",pid=9842,fd=44))                                  
tcp   ESTAB      0      0              10.16.4.131:45290        172.67.72.98:443   users:(("transmission-da",pid=9842,fd=36))                                  
tcp   ESTAB      0      0              10.16.4.131:45280        172.67.72.98:443   users:(("transmission-da",pid=9842,fd=33))                                  
tcp   ESTAB      0      26             10.16.4.131:42065     188.250.132.179:51490 users:(("transmission-da",pid=9842,fd=34))                                  
tcp   ESTAB      0      0              10.16.4.131:45348        172.67.72.98:443   users:(("transmission-da",pid=9842,fd=51))                                  
tcp   ESTAB      0      9              10.16.4.131:42041        146.70.59.48:49313 users:(("transmission-da",pid=9842,fd=43))                                  
tcp   ESTAB      0      0              10.16.4.131:38655          5.79.77.65:42771 users:(("transmission-da",pid=9842,fd=50))                                  
tcp   ESTAB      0      0              10.16.4.131:44441      158.173.152.51:48056 users:(("transmission-da",pid=9842,fd=35))                                  
tcp   ESTAB      0      146            10.16.4.131:33137        85.243.14.91:40202 users:(("transmission-da",pid=9842,fd=29))                                  
tcp   ESTAB      0      485            10.16.4.131:48877       86.106.84.150:47846 users:(("transmission-da",pid=9842,fd=27))                                  
tcp   ESTAB      0      9              10.16.4.131:44885     169.150.223.205:64613 users:(("transmission-da",pid=9842,fd=45))                                  
tcp   ESTAB      0      0              10.16.4.131:50633     169.150.223.215:64062 users:(("transmission-da",pid=9842,fd=38))                                  
tcp   ESTAB      0      0              10.16.4.131:45246        172.67.72.98:443   users:(("transmission-da",pid=9842,fd=21))

Right now you see the source IP as the VPN IP because I have it enabled for everything (not transmission only) but the point is that source ports are a lot.

32

There are the file transfer communications, which are sourcing from the peer-port in the configuration, remote control, which are sourcing from the rpc-port, and the rest (talking to trackers or updating blocklist ) which use random ports.

33

Unless I’m missing something, I believe that’s where the problem lies. How can I ensure that all torrent related traffic goes through the VPN if they use random ports? Maybe I misunderstood your post, but should I be concerned with the “random ports”, the RPC port, Peer Port or all? This may be beyond my knowledge.

Edit:

I think I finally managed to get it working, by doing the first part similar to what you suggest @trendy but then the second part I’m basically doing different, to sum it up:

sudo ip route add default via 172.16.4.1 dev eth0 table 100 // My gateway
sudo ip rule add to 172.16.4.0/24 lookup 100 prio 500 // All traffic through it
sudo ip rule add not uidrange 109-109 lookup 100 prio 1000 // But transmission UID don't

Where the 109 is the Transmission UID. From what I can tell it’s (finally) working and it uses all communications from that user through the VPN whereas the remaining stays on my default WAN/LAN.

1 Like
34

Very good! I believe it was suggested also in the earlier posts to use the uid to mark the transmission traffic.

Apart from that, you may keep the RPC via the normal gateway, so you can control the transmission locally if you wish.

1 Like