Split Tunnel.

[NFO 5]

Split tunneling function in eddie because not everyone can "tinker", because some people see the VPN as a tool and not as a hobby,  and because days don't have more of 24 hours...

So: yes, no, perhaps, go away?

[Staff 9751]

Hello!

In Eddie Android edition you can split traffic on an application basis. You can define "white" and "black" lists of apps. If a black list is defined, the apps included in the black list will have their traffic routed outside the VPN. Any other app will have its traffic routed into the VPN. If you define a white list, only the apps in the white list will have their traffic routed inside. Any other device traffic will be routed outside the VPN. Traffic splitting will work both on WireGuard and on OpenVPN.

In Eddie Desktop edition for Linux, Mac and Windows you can split traffic on a destination basis (IP addresses, IP addresses range, or host names). You can tell Eddie to send the traffic outside the VPN tunnel only for specific destinations, or you can tell Eddie to send all the traffic outside the tunnel except for specific destinations. Traffic splitting will work both on WireGuard and OpenVPN.

AirVPN Suite for Linux does not offer any traffic splitting ability, but we are considering to implement an app based traffic splitting feature in the near future.

Kind regards
 

[jacklollz2 2]

I want to use a split tunnel, that is, specific applications are excluded from the VPN.
https://github.com/tool-maker/VPN_just_for_torrents/wiki/Running-OpenVPN-on-Linux-without-VPN-as-Default-Gateway
This option is unusable. I have the desire to explicitly set certain applications outside the VPN.
Please update this system to include split tunneling like Private Internet Access does.

[NFO 5]

Thank you for these explanations. I will continue the discussion on the other thread where you made the same answer. Thanks again.

[tranquivox69 25]

On 1/27/2023 at 10:09 AM, Staff said:

AirVPN Suite for Linux does not offer any traffic splitting ability, but we are considering to implement an app based traffic splitting feature in the near future.

Any news on this? Moving my server apps to a Linux machine, I would really need to split traffic on a per-app basis in an easy way.

[reversevpn 4]

To split traffic on a per-app basis in your Linux server (assuming you intend to use ipv4), do the following:
1. Install wireguard and systemd-nspawn on your server.
2. Create a new Linux user. The name is up to you, but for the purposes of my answer, let's call this user airapp.
3. For each app that you want to route through AirVPN, start that app under the user airapp. This can be accomplished by using sudo -u airapp [name of app here], or by setting User=airapp in the [Service] section of the app's service file.
4. Edit /etc/iproute2/rt_tables and add a number for a new table we will call vpntable. Again, the name is up to you, but for my answer, we will call this table vpntable.
4. Also in /etc/iproute2/rt_tables, add a number for a new table we will call killswitch. Again, the name is up to you, but for my answer, we will call this table killswitch.
5. Create a systemd-nspawn container, which we will call airouter in my answer(you can change its name; just be consistent with the name you've chosen if you do). Make sure this container starts up along with your server by using systemctl enable systemd-nspawn@airouter && systemctl start systemd-nspawn@airouter. Note that these 2 commands work only after you create the airouter container in /var/lib/machines. If on a Debian or Debian derivative system, you do this using debootstrap(with appropriate arguments). After creating the server, you have to use systemd-nspawn -UD airouter within /var/lib/machines to download and install Linux packages on it, such as systemd-networkd. While in the shell induced by calling systemd-nspawn -UD airouter, the airouter container will temporarily share the networks and interfaces of your host machine, but if you exit this shell and ssh or machinectl login your way into airouter  after executing systemctl start systemd-nspawn@airouter, it will have a network system different from your main server, which is the key to using it as a router for the apps you wish to split-tunnel.
6. Configure systemd-networkd to put both your main server and airouter on the same RFC 1918 network,both with static addresses, but distinct from your server's main network. For example, if your server's physical ethernet card is on 192.168.1.0/24, I suggest you put the ve-airouter interface of your host server and the host0 interface of the airouter container on 192.168.34.0/24. Let us for now pretend that your host server's ve-airouter interface has address 192.168.34.1/24, and that airouter's host0 interface has address 192.168.34.2/14. For now, the default gateway of airouter is the IP address of your server, 192.168.34.1. Also, make it so that airouter sees the link as having an MTU of 1500, but your main server sees the link as having an MTU of 1420. This is to ensure that TCP apps on your server answering back to the airouter container will size their packets appropriately for the wireguard conf you are about to create in airouter.
6. Enable IP masquerading and IP forwarding between the container and your main system, making sure to masquerade traffic heading out of airouter and into AirVPN, traffic heading out of airouter and into your host server, , traffic heading out of your host server and into airouter, and traffic heading out of your host server and onto your server's default gateway.
7. Install wireguard-tools and resolvconf in the airouter container. You may also wish to install openssh-server on airouter so you can manage airouter like any other server.
8. Generate a wireguard config from AirVPN's client area, and put it in the airouter container's /etc/wireguard directory. Let us assume this file is called airvpn.conf, but again you can rename it freely.  I suggest you rename it so that the new name can be used as an interface name, because the default name may have too many characters for the Linux interface system.
9.As root within that container, or using the sudo command, issue systemctl start wg-quick@airvpn && systemctl enable wg-quick@airvpn (must be consistent with the prefix before .conf that you chose in step 8).  This will make it so that the container connects to AirVPN automatically on startup.
10. Establish appropriate firewall rules within the container to block any traffic that you do not need to authorize.
11. On the main server, discover the uid of the newly created airapp user by consulting /etc/passwd or executing the id command as airapp. Let us pretend for now that airapp's uid is 1001.
12. On the main server and as root, enter iptables -t mangle -A OUTPUT -m owner --uid-owner  1001 -j MARK --set-mark 107.(107 is an arbitrary number; you can choose a different one if you like, but make sure to use that same number in the next steps). this marks packets from the airapp user so that they can be routed through airouter later on.
13. As root, enter ip rule add fwmark 107 lookup vpntable prio 100. This will make all traffic from the apps you associated with the airapp user lookup the vpntable instead of your system's main routing table. Add this command to a startup script for your server. 100 is arbitrary, but make sure to pick a number higher than it in the next step.
14.  As root, enter ip rule add fwmark 107 lookup killswitch prio 101. This will make all traffic from the apps you associated with the airapp user lookup the killswitch table if the vpntable is empty or has no applicable routes. Add this command to a startup script for your server.
15.  As root, also enter ip route add default via 192.168.34.2 dev ve-airouter table vpntable.  This route makes the default gateway for the airapp user the airouter container instead of your server's normal default gateway. Also add this command to a startup script for your server, preferably in a while loop to ensure that if the container reboots or starts later than the startup script with this rule, the rule is added nonetheless .
15b. In case you want these apps to be accessible from your LAN also, issue ip route add 192.168.1.0/24 dev eth0 table vpntable. This assumes that your server is on the LAN with subnet 192.168.1.0/24, and that the interface your server is using to connect to the LAN is eth0. Replace eth0 and 192.168.1.0/24 with your actual interface name and subnet. If your server has no connected LAN to speak of, ignore this step.
16.  As root, also issue ip route add default via 127.0.0.1 dev lo table killswitch.  This will make it so that if the apps cannot answer back to the internet through the airouter container(and by extension AirVPN), they cannot answer back to the internet at all. Also add this command to a startup script for your server, preferably in a while loop to ensure that if the container reboots or starts later than the startup script with this rule, the rule is added nonetheless .
17. If the apps accept incoming connections, test them using the Port Forward feature in AirVPN's client area(after using iptables -t nat -I PREROUTING -p- udp --dport X -j DNAT --to 192.168.34.1:X inside the airouter container, where X is the port forward you got from AirVPN). If the apps make outbound connections, ssh into airouter  and install tcpdump, then execute tcpdump -i airvpn as you use the app to verify that traffic from the app is indeed flowing into airvpn, by checking tcpdump as you use the app's networking capabilities. Whenever the app tries to access the network, packets should start appearing on tcpdump's standard output . And about a minute after you close the app (and assuming no other apps you configured to route to airvpn are open either), tcpdump should stop printing new packets to standard out.  I use -i airvpn bgecause I am assuming you rename the downloaded Wireguard profile from step 8 as airvpn.conf. If you instead renamed it as remote.conf,  you should instead execute tcpdump -i remote. The name of the interface you are dumping is also the name you gave the wireguard file.

I strongly suggest using iptables-persistent both on your main server and in the airouter container in order to ensure that all firewall rules, whether in the container or outside it, remain even after a reboot.

If you need more involved help, feel free to message me directly using AirVPN's message feature.

Edited ... by reversevpn
Added an extra MASQUERADE rule from the host server to airouter in step 6

[tranquivox69 25]

17 hours ago, reversevpn said:

To split traffic on a per-app basis in your Linux server (assuming you intend to use ipv4), do the following:

If you need more involved help, feel free to message me directly using AirVPN's message feature.

Hi! First of all an enormous thank you for all the effort. If it doesn't help me, I'm sure it will be useful for people more skilled than me.

I currently use a couple of scripts in Windows, one at session start and one at session end, under the Settings/Events tab of Eddie. And therein lies the problem: I intend to use Eddie and, for the moment, I've decided to avoid using containers (I suppose you refer to Docker and similar).

I post the two scripts here because I thought that in Linux it would have been far easier to handle networking stuff like this and not so much harder, from an enduser point of view. Is the following approach unusable for Linux? Scripts are not mine, they're taken from a forum user here (forever he/she be praised).

VPN Start

@echo adding route entries to hide VPN ...

@rem echo %~n0%~x0
@set temp_file_route=%TEMP%\%~n0%~X0.temp.txt
@rem echo %temp_file_route%
@rem pause

@echo routing table before ...
@route print

@goto GATEWAY4_SET_END
:GATEWAY4_SET
@echo route add   0.0.0.0 mask 192.0.0.0 %1
@echo route add  64.0.0.0 mask 192.0.0.0 %1
@echo route add 128.0.0.0 mask 192.0.0.0 %1
@echo route add 192.0.0.0 mask 192.0.0.0 %1
@route add   0.0.0.0 mask 192.0.0.0 %1
@route add  64.0.0.0 mask 192.0.0.0 %1
@route add 128.0.0.0 mask 192.0.0.0 %1
@route add 192.0.0.0 mask 192.0.0.0 %1
@goto :EOF
:GATEWAY4_SET_END
@route print | findstr /r /c:" 0\.0\.0\.0 *0\.0\.0\.0 " | findstr /v /l /c:" On-link " > "%temp_file_route%"
@rem type "%temp_file_route%"
@rem pause
@for /f "usebackq tokens=3" %%a in (`type "%temp_file_route%"`) do @call :GATEWAY4_SET %%a
@rem pause
@erase "%temp_file_route%"
@rem pause
@rem exit /b

@set FOUND_V6=0
@goto GATEWAY6_SET_END
:GATEWAY6_SET
@set FOUND_V6=1
@echo route -6 add     ::/4 %2 if %1
@echo route -6 add 1000::/4 %2 if %1
@echo route -6 add 2000::/5 %2 if %1
@echo route -6 add 2800::/5 %2 if %1
@echo route -6 add 3000::/5 %2 if %1
@echo route -6 add 3800::/5 %2 if %1
@echo route -6 add fc00::/8 %2 if %1
@echo route -6 add fd00::/8 %2 if %1
@route -6 add     ::/4 %2 if %1
@route -6 add 1000::/4 %2 if %1
@route -6 add 2000::/5 %2 if %1
@route -6 add 2800::/5 %2 if %1
@route -6 add 3000::/5 %2 if %1
@route -6 add 3800::/5 %2 if %1
@route -6 add fc00::/8 %2 if %1
@route -6 add fd00::/8 %2 if %1
@goto :EOF
:GATEWAY6_SET_END
@route print | findstr /r /c:" ::/0 " | findstr /v /l /c:" On-link " > "%temp_file_route%"
@rem type "%temp_file_route%"
@rem pause
@for /f "usebackq tokens=1,4" %%a in (`type "%temp_file_route%"`) do @call :GATEWAY6_SET %%a %%b
@rem pause
@erase "%temp_file_route%"
@if %FOUND_V6%==0 @call :GATEWAY6_SET 1 ::
@rem pause
@rem exit /b

@echo routing table after ...
@route print

@pause

VPN End
 

@rem echo %~d0%~p0NET_gateway_set.bat
@rem call %~d0%~p0NET_gateway_set.bat

@echo removing entries to show VPN ...

@route delete 0.0.0.0 mask 192.0.0.0
@route delete 64.0.0.0 mask 192.0.0.0
@route delete 128.0.0.0 mask 192.0.0.0
@route delete 192.0.0.0 mask 192.0.0.0
@route -6 delete ::/4 
@route -6 delete 1000::/4
@route -6 delete 2000::/5
@route -6 delete 2800::/5
@route -6 delete 3000::/5
@route -6 delete 3800::/5
@route -6 delete fc00::/8
@route -6 delete fd00::/8

@route print

@pause

[reversevpn 4]

26 minutes ago, tranquivox69 said:

Hi! First of all an enormous thank you for all the effort. If it doesn't help me, I'm sure it will be useful for people more skilled than me.
...

@pause

I suppose an approach like this might work if you only ran 1 app at a time, but if you want to run several apps concurrently, and the apps you intend to run concurrently are a mix of apps you want to run through AirVPN and apps that you don't want to run through AirVPN, the cheapest option is to use systemd-nspawn, a container that is well-integrated into Linux's systemd.  Additionally, it appears that script is written in batch script, so if you want to use that same approach in Linux, you will have to rewrite it in bash. Alternatively, if you can spare an extra physical linux machine, like a mini PC, a raspberry pi, an old laptop or old desktop, etc., that physical machine can be used instead of a systemd-nspawn container. Edited ... by reversevpn
Shorten quotation using ellipsis for improved forum readability

[tranquivox69 25]

24 minutes ago, reversevpn said:

I suppose an approach like this might work if you only ran 1 app at a time, but if you want to run several apps concurrently, and the apps you intend to run concurrently are a mix of apps you want to run through AirVPN and apps that you don't want to run through AirVPN, the cheapest option is to use systemd-nspawn, a container that is well-integrated into Linux's systemd.  Additionally, it appears that script is written in batch script, so if you want to use that same approach in Linux, you will have to rewrite it in bash. Alternatively, if you can spare an extra physical linux machine, like a mini PC, a raspberry pi, an old laptop or old desktop, etc., that physical machine can be used instead of a systemd-nspawn container. 

What happens when using that approach is that I need to bind the applications I want to use under VPN to a specific network interface. qBittorrent allows it and other torrenting software too.

In Windows there's a small program (ForceBindIP) that injects before launching whatever software and does the same. So I have qBittorrent under VPN, Firefox launched through ForceBindIP and other browsers and programs running outside VPN, as the whole of the system does.

For Linux I might content myself with just having qB under VPN. As far as translating batch to bash... Linux newbie here, I wouldn't know where to begin from (and considering the security and privacy implications I wouldn't want to learn by trial and error). As I wrote, I wrongly assumed this would have been much easier under Linux, as I remember reading, years ago, when I was inquiring about a solution for Windows, stuff like "if you were using Linux it'd be a piece of cake". Not so much, it appears 😞

Thanks again!

[tranquivox69 25]

Tried using ChatGPT to convert... problem is while the bash syntax might be correct (I don't have a clue about that), I suppose the instructions to do the different things are not

VPN Hide bash

 

#!/bin/bash
echo "adding route entries to hide VPN ..."

temp_file_route=$(mktemp)

echo "routing table before ..."
route -n

function GATEWAY4_SET {
    echo "route add   0.0.0.0 netmask 192.0.0.0 $1"
    echo "route add  64.0.0.0 netmask 192.0.0.0 $1"
    echo "route add 128.0.0.0 netmask 192.0.0.0 $1"
    echo "route add 192.0.0.0 netmask 192.0.0.0 $1"
    route add   0.0.0.0 netmask 192.0.0.0 $1
    route add  64.0.0.0 netmask 192.0.0.0 $1
    route add 128.0.0.0 netmask 192.0.0.0 $1
    route add 192.0.0.0 netmask 192.0.0.0 $1
}

route -n | grep -E " 0\.0\.0\.0 *.*" | grep -v "On-link" > "$temp_file_route"

while read -r line; do
    GATEWAY4_SET $(echo "$line" | awk '{print $3}')
done < "$temp_file_route"

rm "$temp_file_route"

FOUND_V6=1

function GATEWAY6_SET {
    FOUND_V6=1
    echo "route -6 add     ::/4 $2 dev $1"
    echo "route -6 add 100::/4 $2 dev $1"
    echo "route -6 add 200::/5 $2 dev $1"
    echo "route -6 add 280::/5 $2 dev $1"
    echo "route -6 add 300::/5 $2 dev $1"
    echo "route -6 add 380::/5 $2 dev $1"
    echo "route -6 add fc00::/8 $2 dev $1"
    echo "route -6 add fd00::/8 $2 dev $1"
    route -6 add     ::/4 $2 dev $1
    route -6 add   100::/4 $2 dev $1
    route -6 add   200::/5 $2 dev $1
    route -6 add   280::/5 $2 dev $1
    route -6 add   300::/5 $2 dev $1
    route -6 add   380::/5 $2 dev $1
    route -6 add fc00::/8 $2 dev $1
    route -6 add fd00::/8 $2 dev $1
}

route -n | grep "::/.*" | grep -v "On-link" > "$temp_file_route"

while read -r line; do
    GATEWAY6_SET $(echo "$line" | awk '{print$4,$3}')
done < "$temp_file_route"

rm "$temp_file_route"

if [ "$FOUND_V6" == "1" ]; then
    GATEWAY6_SET eth :: 
fi

echo "routing table after ..."
route -n

read -p "Press enter to continue"

VPN Show bash
 

#!/bin/bash
echo "removing entries to show VPN ..."

route delete 0.0.0.0 netmask 192.0.0.0
route delete 64.0.0.0 netmask 192.0.0.0
route delete 128.0.0.0 netmask 192.0.0.0
route delete 192.0.0.0 netmask 192.0.0.0
route -6 delete ::/4 
route -6 delete 100::/4
route -6 delete 200::/5
route -6 delete 280::/5
route -6 delete 300::/5
route -6 delete 380::/5
route -6 delete fc00::/8
route -6 delete fd00::/8

route -n

read -p "Press enter to continue"

 

[reversevpn 4]

https://github.com/Intika-Linux-Firewall/App-Route-Jail
Perhaps this may be of interest to you. This essentially does the same thing as ForceBindIP, with a few extra steps. I do not vouch for the security of this code, but this does appear to be very close to your existing solution.

[reversevpn 4]

As for the converted bash script, I don't think it will work as-is because the On-Link keyword that it expects is not present in Linux's route -n. That being said, if your motivation behind using the original script is just to prevent Eddie from making AirVPN your system's default gateway, you can accomplish that effect by adding route-nopull to Eddie's Settings>OpenVPN directives.

[tranquivox69 25]

9 hours ago, reversevpn said:

As for the converted bash script, I don't think it will work as-is because the On-Link keyword that it expects is not present in Linux's route -n. That being said, if your motivation behind using the original script is just to prevent Eddie from making AirVPN your system's default gateway, you can accomplish that effect by adding route-nopull to Eddie's Settings>OpenVPN directives.

And that simple directive would achieve... what exactly?
All traffic outside VPN unless bound to the VPN adapter by an application (like qBittorrent does)? So simple? Please tell me it's true...

I suppose there is no equivalent if I wanted to use Wireguard protocol, right?

[reversevpn 4]

That directive prevents AirVPN from making itself the default gateway of your system. This will indeed cause your system to continue sending most traffic outside the VPN tunnel. As for only applications bound to that interface using the VPN, that does appear to be the case in my experiments involving Linux ISOs, but I suggest you conduct your own experiments as well to verify. Torrent testing tools like ipleak.net do not seem to be able to detect a torrent client configured this way, but a torrent client configured this way does actually succeed in downloading Linux ISOs, a tcpdump of the VPN interface does reveal packets flowing through the VPN, and an nload of the VPN interface reveals a significant amount of traffic flowing through it when the torrent client is activated and bound to the eddie interface.

Additionally, to make the name of the interface that Eddie creates predictable, I suggest you replace the line that says
dev tun

with two lines that say

dev eddie
dev-type tun

This will cause eddie's VPN interface to always be named "eddie" rather than tun0, tun1, etc.

If you want to achieve the same effect using Wireguard, you will have to manipulate the routing policy database after allowing 0.0.0.0/0. ::/0 for Air's server in the Wireguard conf itself. This involves multiple ip rule commands executed after the wireguard interface is raised , and making a mistake may cause you to lose remote access to your server, which would force you to physicaly go to your server to correct the mistake. I do not do this because I prefer the container method since it does not require me to override Wireguard's default behavior.

[tranquivox69 25]

2 hours ago, reversevpn said:

That directive prevents AirVPN from making itself the default gateway of your system. This will indeed cause your system to continue sending most traffic outside the VPN tunnel. As for only applications bound to that interface using the VPN, that does appear to be the case in my experiments involving Linux ISOs, but I suggest you conduct your own experiments as well to verify. Torrent testing tools like ipleak.net do not seem to be able to detect a torrent client configured this way, but a torrent client configured this way does actually succeed in downloading Linux ISOs, a tcpdump of the VPN interface does reveal packets flowing through the VPN, and an nload of the VPN interface reveals a significant amount of traffic flowing through it when the torrent client is activated and bound to the eddie interface.

Additionally, to make the name of the interface that Eddie creates predictable, I suggest you replace the line that says
dev tun

with two lines that say

dev eddie
dev-type tun

This will cause eddie's VPN interface to always be named "eddie" rather than tun0, tun1, etc.

If you want to achieve the same effect using Wireguard, you will have to manipulate the routing policy database after allowing 0.0.0.0/0. ::/0 for Air's server in the Wireguard conf itself. This involves multiple ip rule commands executed after the wireguard interface is raised , and making a mistake may cause you to lose remote access to your server, which would force you to physicaly go to your server to correct the mistake. I do not do this because I prefer the container method since it does not require me to override Wireguard's default behavior. 

Well, thank you so much!
Great suggestion on VPN name, I was wondering how to do that. My first days with Linux... I have to relearn stuff I accumulated for Windows in almost thirty years of use... 😕

I will clearly conduct some testing myself, kinda worried about ipleak not being able to detect torrents with that method (mostly because all the other things one can check you refer to kinda fly over my head 🙂).

As for Wireguard, since from what I've gathered Eddie uses Wireguard if it finds it in the Kernel (I have version 1.0.0), I suppose the configuration you mention is the one on the OS itself and not in Eddie. Am I right? In that case, I will need to find where it is.

Luckily the server is not remote and is not headless, so checking stuff it's rather easy for me.
But above all, once more, thank you! All this is much, much appreciated.
 

[reversevpn 4]

Indeed, the use of ip rule manipulates the OS rather than Eddie. That sort of manipulation undoes the default routing policy database that wg-quick would normally do upon gateway redirection. The advantage of this method is that you would not need to enter wireguard parameters manually. Perhaps you would want to use the wg tool manually in order to avoid having to undo anything at all, but the drawback is that you would have to enter parameters manually.  There are steps for using wg rather than wg-quick on wireguard.com. Either way, these manipulations are all performed outside Eddie. As far as I can tell, Eddie does not allow Wireguard customization.
If you don't want to use tcpdump for packet inspection during your experiments, you can use Wireshark instead. It's a GUI tool for packet inspection of individual interfaces, and you can use it because your system is not headless. Just select the eddie interface from Wireshark's list of interfaces, after you have activated Eddie and instructed it to name its interface eddie.

[NaDre 154]

3 hours ago, reversevpn said:

Indeed, the use of ip rule ...

This will be too technical for most. So maybe this is just between you and me.

I wonder if applying SO_MARK on all sockets for an application might not interfere with programs like transmission-daemon that provide a API/web interface on the localhost IP?

Also, if you use transmission-daemon without the VPN as default gateway, it will leak your IPv6 address in tracker announces.

Search for "ipv6=" here:

https://github.com/transmission/transmission/blob/3.00/libtransmission/announcer-http.c

Search for "2001:1890:1112:1::20" here:

https://github.com/transmission/transmission/blob/3.00/libtransmission/net.c

One private tracker site I use actually detects that the "ipv6=" (deprecated) option has been used in the announce and warns you. I am not sure if the leak occurs in DHT too.

I don't think using SO_MARK in that way would stop this either.

I use an LD_PRELOAD shim that intercepts "bind" et al. It does stop this.

Since we are getting technical, I wounder if staff would like to give some insight on how the new release of Eddie will go about achieving split tunneling per program instance.

 

[reversevpn 4]

Well, my recommended technique is to use systemd-nspawn containers,  IP Masquerading, policy-based routing, and user-based packet mangling to achieve split-tunnel behavior. As for ipv6, you can block ipv6 traffic for transmission entirely by using the -m owner --uid owner option in ip6tables filter table, OUTPUT chain, provided that you run transmission as another linux user. To continue allowing local routing to work, simply add a route for the local network for the user-specific routing table that you make for the transmission user account. See my first anwer to this problem for how to deploy such a setup. The advantage of that method is that there is no need for the application to cooperate with IP binding; you enforce split tunneling through the OS. Actually, come to think of it, if you suspect a program to be leaking your ipv6 address, I suggest you just run it inside the systemd-nspawn container configured with no ipv6 address instead of running it in the host OS and routing traffic through the container. That would completely negate the need for advanced tricks like packet mangling.

[NaDre 154]

5 minutes ago, reversevpn said:

... As for ipv6, you can block ipv6 traffic for transmission ...

I believe the "ipv6=" is sent using IPv4 too. It is an option in the tracker announce. And I think most folks would want IPv6 to work.

The point is that the app itself is revealing information that it should not.

This may not be a big issue. But since your link was to an LD_PRELOAD shim, I thought I should mention that there are other LD_PRELOAD shims that approach things differently.


 

[reversevpn 4]

In that case, transmission should be confined to a systemd-nspawn container that has only a local ipv4 and the ipv4 and ipv6 addresses assigned by AirVPN. This container would not have the ipv6 of the host, having its own network namespace. You can continue to use ipv6 as you wish in the host OS while leaving transmission with only a harmless internal IP address and IP addresses from AirVPN.

[reversevpn 4]

If you want to continue using the web API of transmission, simply configure the host OS to forward packets from the remote device to the transmission remote control port, while masquerading such requests. This will cause transmission to answer back to the host OS's internal IP address, and the host OS will ultimately answer back to the web API's consumer. 

[NaDre 154]

Containerizing things is no doubt more secure. But requires much more work and technical skill.

Many rely on containers that are written with great enthusiasm, and then very quickly abandoned by the author. Maybe after they graduate? I see posts in forums all the time about how the containerized version of qbittorrent they have been using isn't being updated. Or they want know how they can browse through the VPN too. Or run some other app through the VPN. Not just qBittorrent.

And this brings me back to wondering what approach AirVPN will take inside Eddie.
 

[NaDre 154]

On 4/9/2023 at 3:51 AM, tranquivox69 said:

...

I currently use a couple of scripts in Windows, one at session start and one at session end, under the Settings/Events tab of Eddie. And therein lies the problem: I intend to use Eddie and, for the moment, I've decided to avoid using containers (I suppose you refer to Docker and similar).

I post the two scripts here ...

Of course those came originally from the wiki I wrote on github.

I guess the scripts I posted there for Linux are not appealing because they do not use Eddie.

I don't use Eddie. So I would not want to invest a huge effort coming up with scripts to accommodate Eddie. Particularly since AirVPN is about to release a version of Eddie that will address this.

But you could have a script that overrides the VPN gateway in exactly the same way that Windows script does, By adding routing table entries that will hide the routing table entries the VPN will install. You could run it before you start Eddie. Or have Eddie start it as you do in Windows. It would need to determine what the original gateway IP address was. Or you might be able to just hard-code that. Does it change when you reboot? Depends on your router settings.

The problem is that on Linux, unlike Windows, this does not set up source address routing for you. You would need another script to use the ip command after the VPN has come up to do that. There is an example in my wiki page about Linux. That script would have to determine the VPN IP addresses to use. For Wireguard the addresses shouldn't change when you switch servers. So you could just hard-code them. In fact, for Wireguard, if you hard-code them you might be able to do that in the same script that hides the VPN gateway. I think Eddie may let you run that second script automatically, after the VPN is up.

Then you could bind qbittorrent to the VPN interface for OpenVPN or to the VPN address for Wireguard.

Hope that helps.

My approach is to offer information on how to "do it yourself" to folks who are willing to learn. Because I do not want to promise to maintain some software package. Even  the scripts I put in the wiki are just meant as examples.
 

[reversevpn 4]

systemd-nspawn is deeply tied to systemd, which is a major part of most Linux distributions today. I seriously doubt it will be abandoned any time soon. What I am suggesting is not the download and use of a pre-built container, but rather to setup the container yourself as though it were a server distinct from the hosting server, then to install applications on it as though it were another server.

[reversevpn 4]

10 minutes ago, NaDre said:

Of course those came originally from the wiki I wrote on github.

I guess the scripts I posted there for Linux are not appealing because they do not use Eddie.

I don't use Eddie. So I would not want to invest a huge effort coming up with scripts to accommodate Eddie. Particularly since AirVPN is about to release a version of Eddie that will address this.

But you could have a script that overrides the VPN gateway in exactly the same way that Windows script does, By adding routing table entries that will hide the routing table entries the VPN will install. You could run it before you start Eddie. Or have Eddie start it as you do in Windows. It would need to determine what the original gateway IP address was. Or you might be able to just hard-code that. Does it change when you reboot? Depends on your router settings.

The problem is that on Linux, unlike Windows, this does not set up source address routing for you. You would need another script to use the ip command after the VPN has come up to do that. There is an example in my wiki page about Linux. That script would have to determine the VPN IP addresses to use. For Wireguard the addresses shouldn't change when you switch servers. So you could just hard-code them. I think Eddie may let you run that second script automatically, after the VPN is up.

Then you could then bind qbittorrent to the VPN interface for OpenVPN or to the VPN address for Wireguard.

Hope that helps.

My approach is to offer information on how to "do it yourself" to folks who are willing to learn. Because I do not want to promise to maintain some software package. Even  the scripts I put in the wiki are just meant as examples.
 

I wonder though, why do you hide the VPN's routing table entries instead of just not pulling them in at all? If they are hidden anyway, what good does it do for them to enter the routing table in the first place?