guide The Guide for Torrenting, split-tunneling, killswitch and all the other buzzwords

[guidance 7]

This guide will explain how to setup OpenVPN in a way such that only select programs will be able to use the VPN connection while all other life continues as usual.

Please read this notice before applying the guide

Advantages:

• fail-free "kill switch" functionality (actually better than 98% of VPNs out there)
• continue using another VPN as primary or don't reroute any other traffic at all
• nobody, not even peers on LAN, will be able to connect to your torrent client (the only way: through the VPN connection) - eliminating unintended leaks

Disadvantage:

• the apps will still use your default DNS for hostname lookups (secure your DNS separately!)

See two more drawings at the end.
The guide is applicable to all VPN providers who don't restrict their users to use the OpenVPN client. The method however is universally applicable.

It was made with examples from Windows, but with Linux/BSD you will only need little tweaking to do. Specifically, net_gateway placeholder may not available and that's all there is to it. Android clients are probably too limited for this task and lack options we need.
-
Since there'll be a lot of text, sections titled in (parantheses) are entirely optional to read. The other guide by NaDre is old (2013), hard to read and pursues a slightly different approach. A Staff member actually posted a good first comment there, that's what we're gonna do.

(Preface)

The BitTorrent as a network is entirely public. Through the decentralized technology called DHT, everyone in the world can find out what torrents you are presumably participating in (this does not apply to private trackers who disable DHT).
Clearly this creates an unhealthy atmosphere for privacy of users, e.g. one could find out the OS distribution one is using for a more targetted attack etc.
Sometimes the ISPs are outright hostile to peer-to-peer technologies due to the traffic and bandwidth these are consuming. Instead of upgrading dated infrastructure, they cripple their users instead.

There are many reasons to use a VPN, that was but a limited selection.

("Split-tunneling")

This has become somewhat a marketing term nowadays, but actually explains the nature of the traffic flow well. In this guide only the programs set to use the VPN connection will use it, nothing else.
All your traffic goes past the VPN while torrent client traffic (or any other selected program) uses only the VPN connection.

("Kill switch")

We'll literally nail it using software settings of your program (the torrent client).
This is a marketing-loaded name. In short: if the VPN connection is not available, no traffic ought to be sent bypassing it. In most cases where you have a VPN redirect all your system traffic - you should not rely on it as a feature. The OpenVPN software on Windows is not 100% proof, based on empirical evidence (reconnects and startup/shutdown phases) and some other VPN providers do no better (based on comments and stories). The only bulletproof solution: the VPN tunnel is set up on an intermediary device your PC is connected to - your end device (the PC) has no chance whatsoever to bypass the tunnel in that case.
If the VPN provider uses a firewall under the hood, that's good too but with this guide you will not need a firewall nor rely on the VPN software.

("Dual-hop")

With the knowledge and methods from this guide you will be able to daisy-chain multiple VPN servers. In essence, your traffic passes PC->VPN1->VPN2->Destination. This was not intended for this guide nor with AirVPN, it's finicky and I wouldn't recommend it myself without a real need and skills to automate the setup and configuration.

How it will work

Many users (aka mostly idiots on Reddit) are running in circles like qBittorrent is the only client (or probably the only application in the universe, unconfirmed) that can be set to use a certain VPN.

Here's the technicality: this is called 'binding' - you can 'bind to IP' which will force the app to use a specific IP address and nothing else. If it cannot use the IP (when VPN is disconnected) then it will not be able to do any networking at all. The OS will deny any communication with the internet: boom! Here's your praised 'kill switch' and 'split-tunneling', 2-in-1. This is the next best bulletproof solution (the only better alternative is to use an intermediary VPN device, as any software could choose a different interface now to communicate with the internet).
In a broader sense, you want to 'bind to a network interface' - your client will use any available IPs from the VPN interface - making it ready for IPv4 and IPv6. Oh and you don't need to change the IP once the VPN connection changes to another server. The OS handles the rest.

Examples of programs that can bind to user-defined addresses include:

(Windows) ping, tracert (IPv6-only, WTF?), curl and wget, and many others, including your favorite torrent client

You will find guides online how to do that in your client or just look in settings.

(Linux-specific differences of the guide)

If you are a Linux/*nix user, there're some minor changes to the quick guide below:

* Create custom VPN interface:
Create with ip tuntap command. The below line will create 5 interfaces "tun-air1" etc. for YOUR user. Specifying your user allows OpenVPN to drop root rights after connection and run under your user (security). AirVPN allows up to 5 connections. If you have no use for this, create only one.
Note: User-owned tunnel interfaces allow to be used by your non-root $user account, but there're issues with running OpenVPN without elevated permissions as $user
user="$(whoami)"; for i in {1..5}; do sudo ip tuntap add dev "tun-airvpn$i" mode tun user "$user" group "$user"; done
Check their existance with ip -d a -- the interfaces will not be shown under /dev/tun*
ALTERNATIVE: openvpn --mktap/--mktun. See manual with man openvpn

* Select custom VPN interface:
This config part differs from Windows, very confusing. Steps:
1. Replace "dev-node" in config with "dev"
2. Add "dev-type tun" or "tap".
Example of config:
# if you have these defined multiple times, last entries override previous entries
dev tun-airvpn1 # previously dev-node
dev-type tun # previously "dev tun" on Windows

There're no more differences.

In-depth explanation: If you try to use dev-node like for Windows, you will see:
OpenVPN log: ERROR: Cannot open TUN/TAP dev /dev/tun-airvpn1: No such file or directory (errno=2)
Example strace of error: openat(AT_FDCWD, "/dev/tun-airvpn1", O_RDWR) = -1 ENOENT (No such file or directory)
OpenVPN cannot find the TUN/TAP with the name? No, on Linux/*nix/*BSD dev-node has a totally different meaning. Dev-node specifies where the control interface with the kernel is located. On Linux it's usually /dev/node/tun, for the "mknode" command. If OpenVPN can't detect it for some reason, then you'd need to use dev-node.

Finally you can start OpenVPN from terminal: sudo openvpn --config 'path/to/config.ovpn' --user mysystemusername --group mysystemusergroup
PS: There're issues when running OpenVPN under your current $user. I think the problem was that it couldn't remove added routes after a disconnect. Instead run OpenVPN as root (isn't a good advice but it's what works)

 

Windows Quick Guide

1. Go to the folder where you installed OpenVPN and its exe files: 'C:\Program Files\OpenVPN\'
2. Open CMD inside the 'bin' folder: Hold Shift + Right Click the 'bin' folder -> 'Open Command Window here'
3. We will use tapctl.exe to create a new VPN network interface solely for use with AirVPN (to look around: run "tapctl.exe" or "tapctl.exe help")

   1. C:\Program Files\OpenVPN\bin>tapctl create --name AirVPN-TAP
      {FDA13378-69B9-9000-8FFE-C52DEADBEEF0}
      
      C:\Program Files\OpenVPN\bin>

      A TAP interface is created by default. I have not played enough with Wireguard's TUN to recommend it.
   2. You can check it out, it will be under adapters in your Windows network settings
4. Important: Configure your app/torrent client to use this 'AirVPN-TAP' interface. This is what ensures your traffic never leaks.
   1. It may appear under a different name, in such case find out which one it is in the output of 'ipconfig /all' (enter this into CMD)
   2. If your client does not allow to bind to a general interface but a specific IP (poor decision) then connect to the VPN first to find out the local IP within the VPN network. In this case with AirVPN you may only use one single server or you'll have to constantly change the IP in settings.
5. Generate AirVPN configs where you connect to the server via IPv4! This is important
6. Add these to the .ovpn config files (either under 'Advanced' on the config generator page or manually to each config file)

   # NOPULL START
   route-nopull
   
   # IF YOU DO NOT USE ANOTHER VPN THAT TAKES OVER ALL YOUR TRAFFIC, USE "net_gateway" (just copy-paste all of this)
   # net_gateway WILL BE AUTOMATICALLY DETERMINED AND WILL WORK IF YOU CONNECT THROUGH OTHER NETWORKS LIKE A PUBLIC WIFI
   # personally, due to a second VPN, I had to specify my router IP explicitly instead of net_gateway: 192.168.69.1
   # "default"/"vpn_gateway"/"remote_host"/"net_gateway" are allowed placeholders for IPv4
   
   route remote_host 255.255.255.255 net_gateway
   route 10.0.0.0 255.0.0.0 vpn_gateway
   route 0.0.0.0 0.0.0.0 default 666
   route-ipv6 ::/0 default 666
   dev-node AirVPN-TAP
   
   # END OF NOPULL

7. Test if the configuration works. Full tests, don't leave it up to chance.

In-depth explanation of the OpenVPN config

• route-nopull
  • rejects any networking routes pushed to you by the server, we will write our own
• route remote_host 255.255.255.255 <router IP>
  • we tell our system that, to reach remote_host (the AirVPN server IP), it must send traffic to <router IP>. The subnet mask 255.255.255.255 says that this only applies to this single IP
    • set <router IP> to be net_gateway (only for Windows users, check availability on other platforms)
    • <router IP> may be any of the OpenVPN placeholders too, for example "net_gateway" should work universally (you avoid hard-coding the router IP and if it ever changes: wondering years later why the config no longer works)
    • <router IP> is "192.168.1.1" in my case, for my home router that connects me to the internet.
• route 10.0.0.0 255.0.0.0 vpn_gateway
  • we tell our system that all 10.x.x.x traffic will be sent to the AirVPN server
    • the internal VPN network with AirVPN is always on the 10.0.0.0 - 10.255.255.255 network range. The subnet mask reflects that. However this may interfere with other VPNs if you ever need to be connected to both at once. I will not go into detail on this. What you need to do is to be more specific with 10.x.x.x routes in this config, i.e. instead of /8 subnet, only route the specific /24 subnet of the current VPN server (AirVPN uses a /24 subnet for your connections on each VPN server -> 10.a.b.0 255.255.255.0)
    • vpn_gateway is one of OpenVPN placeholders
• route 0.0.0.0 0.0.0.0 default 666
  • allow routing of ANY traffic via the VPN
  • we set the metric to 666, metric defined as path cost (historically) so setting it to a high value will make sure no normal connection runs through it, unless specifically bound to the VPN IP.
• route-ipv6 ::/0 default 666
  • same for IPv6. How many can claim they have working VPN IPv6 setup? Welcome in the future. IPv6 is over 20 years old at this point anyhow.
• dev-node AirVPN-TAP
  • (Windows-only) tell OpenVPN to ONLY use this network interface to create the VPN tunnel on. Nothing should interfere with our setup now

That's all, folks!
Note: Somehow on Windows my AirVPN connection receives a wrong internal IP that doesn't enable networking at first. In my case I need to wait 1-3 minutes until OpenVPN reconnects itself based on ping timeout: after the reconnect I receive another IP and everything starts to work. I do not know whether it's an OpenVPN or a Windows bug.

One last note: using multiple VPNs

Actually this will work, that's how I roll. As long as both VPNs don't clash by using the same 10.0.0.0/8 subnet. If this happens, you will need to change Line 5 to point to a more specific (aka smaller) subnet tailored to your AirVPN server. Specifying a 10.x.x.0/24 subnet for routing will surely do (subnet mask: 255.255.255.0). Just be aware that you cannot practically use the same IP range in both networks at the same time (well, you'd need to bind the application you are using to either interface, which you cannot do with a browser or the printing service in case of internal resources).

(The story of broken net_gateway)

For this placeholder, OpenVPN attempts to determine your 'default gateway', i.e. the router all your internet traffic passes through. It normally works, but may not be supported on other platforms (Linux, sigh). However it has one unintended side-effect: if you already have a VPN that reroutes all your traffic, net_gateway will make all AirVPN traffic go through the first VPN:

Your traffic -> VPN1 -> Internet
Torrent traffic -> VPN1 -> AirVPN -> Internet

That's the unintended dual-hop. Surely you can extend that scheme to 3,4,n-hops if you fiddle enough with routing, subnet masks and correct order. I'm not responsible for headaches
We avoid that behavior with Line 4 from our config - the remote_host line forces the AirVPN traffic to go straight to the internet (through your LAN router).

One more thing: net_gateway is not available for IPv6 routes in OpenVPN. That's why it currently only works with a IPv4 connection to the VPN server.

(Crash course: Subnet masks)

You've seen the weird number 255.0.0.0 above. You should refer to other pages for a proper explanation, but basically this is a very simple way for computers to determine the range of IP addresses that are part of a network (a subnet). What's simple for computers is very hard to grasp for us humans.
255 means there are NO changes allowed to the first set of IP numbers. I.e. the 10 in 10.0.0.0 always stays a 10.
0 means all numbers can be used. I.e. the zeroes in 10.0.0.0 can be (0-255), lowest address is 10.0.0.1 and the last address is 10.255.255.254 (technically, 10.0.0.0 is the first and the last 10.255.255.255 is reserved for 'broadcast')
Any number in between denotes ... a range in between. 2^(32-prefix)=number. Number is the amount of available addresses and prefix is called the subnet prefix. Both are meant to describe the same thing.
For 10.0.0.0/26 or 10.0.0.0 with subnet mask of 255.255.255.192 you get addresses in range 10.0.0.0-10.0.0.64 -- 2^(32-26) = 64. Similarly you can convert the subnet mask into the prefix number and work from there; or eyeball it: 256-192 = 64.

(Two ways to accomplish routing)

If you have two equal routes, e.g.

1. 0.0.0.0 goes through VPN with metric 666
2. 0.0.0.0 goes through LAN router with metric 10

then obviously the default route for a packet will travel through (2) - because it's a cheaper path. Unless an application specifies to talk only on the VPN interface.

However a different rule applies whenever a more specific route exists

1. 0.0.0.0/0 goes through VPN2 with metric 666
2. 0.0.0.0/0 goes through LAN router with metric 10
3. 0.0.0.0/1 goes through VPN1 with metric 30
4. 128.0.0.0/1 goes through VPN1 with metric 30

Here the routes (3) and (4) cover the entire addressing space, just like 0.0.0.0/0. However because they are more specific, they'll be preferred for all traffic because these routes are more selective. This is how OpenVPN does override system routing with VPN routing by default. This is also what the other guide attempted as well, by pushing four {0,64,128,192}.0.0.0/2 routes. Since that was more specific, it would in return override the 0,128 routes and so on.
We can calculate how many multi-hops we would be able to do with this method: IPv4 has 32 bits, we will not touch the last 8 bits of the subnets. That leaves us then with 24 bits or 24 maximum amount of hops. Theoretically. The routing table would be outright f---- to look at.
This method is a bit more 'secure' in a way because you don't need to rely on overriding a certain metric value, you just slap a more specific route on top and it's automatically made default. Also you don't need to override the default gateway (router) and all that junk.

However with my preferred method (first) you can quite easily do DIY dual-hop routing:

1. 0.0.0.0/0 goes through VPN2 with metric 666
2. 0.0.0.0/0 goes through LAN router with metric 10
3. 0.0.0.0/1 goes through VPN1 with metric 30
4. 128.0.0.0/1 goes through VPN1 with metric 30
5. <VPN2-IP>/32 goes through VPN1 with metric (any)

Such a setup will make sure that all traffic destined for the internet (hits 3 and 4) will go through VPN1. If a program specifies the VPN2 network interface, then VPN2 will be reached via VPN1 first (you->VPN1->VPN2). This is quite 'quizzacious' to set up/control. Not part of this guide. As a part of this guide we told the system to route VPN2 via router on LAN.
Yet you could indeed chain multiple VPNs this way and force the VPN1 to not only catch all traffic but also be chained via multiple VPNs itself so you would not need to manually set programs. I've seen scripts online for that purpose. Although be aware of MTU issues due to encapsulation.

Troubleshooting tips

TEST. SERIOUSLY, TEST YOUR SETUP BEFORE ENGAGING YOUR DATA CANNONS!
A couple hours now are infinitely many times more worth than a 'leaked' mistake and headaches later on.
https://ipleak.net/ - tests your client's default connection route. It would not tell you if your client is alternatively available on LAN for example. If you followed this guide and set up your client correctly, it will not be available on LAN etc. See the images below: 'without interface binding' (most newbie users) and 'with interface binding' (this guide)
Wireshark to inspect how the traffic is actually flowing. Follow online tutorials, you only need to select the right network interfaces and filter traffic by port/IP (tcp/udp and your local or VPN IP)
curl to send network requests. Like ifconfig.co / ifconfig.io will respond with the IP address it sees you as:

curl --interface <your computer IP> http://ifconfig.co
curl --interface 192.168.1.42 http://ifconfig.co
# for IPv4 or IPv6, default route
curl -4 http://ifconfig.co
curl -6 http://ifconfig.co

> route -4 print

and

> route -6 print

on Windows. To compare the outputs, you can use Notepad++ with the compare plugin (you need two documents open, one in left and another in right pane before comparing).

PS:

AirVPN configuration generator does not support #comment lines. Please fix.
Sorry Linux users, maybe another time I will write something tailored to you. But I believe you are smart cookies and will adapt the OS-specific steps to fulfill this guide's goal.




  Edited ... by guidance
Warning about running OpenVPN as non-root on Linux

[OpenSourcerer 1435]

Wow, a guide! Thank you very much for the work you put into it. I'll probably test it out one of these days.
 

4 hours ago, guidance said:

Specifically, net_gateway placeholder is not available afaik and that's all there is to it.

This is false. It is available and working as intended on Linux.
 

4 hours ago, guidance said:

One more thing: net_gateway is not available for IPv6 routes in OpenVPN

This is true, though. But in all fairness, most directives in OpenVPN refer to v4 only.
 

Quote

But I believe you are smart cookies and will adapt the OS-specific steps to fulfill this guide's goal.

One thing came to mind when I read this:

[NaDre 157]

For what it is worth, I have seen on Windows that routing metrics may be ignored in some instances.

I once used a method that relied on route metrics. The VPN would not be used unless a program was bound to the VPN interface. But one day while using a Usenet client with many connections to the server I noticed that for some connections the route with a worse metric was chosen.

EDIT:

By the way, you said "only select programs will be able to use the VPN connection". It appears to  me that traffic splitting here is done based on the destination of the connection, not based on which program is making the connection. Or did I miss something?
 

[guidance 7]

Thanks guys.

9 hours ago, OpenSourcerer said:

This is false. It is available and working as intended on Linux.

It's not available in the NetworkManager interface, maybe if you talk to OpenVPN directly it will work. But it's also written like this in the documentation:

Quote

net_gateway — The pre-existing IP default gateway, read from the routing table (not supported on all OSes).

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/
 

9 hours ago, OpenSourcerer said:

most directives in OpenVPN refer to v4 only

For those interested, here's the issue link for IPv6 support. It will be fixed within a year if we're lucky  https://community.openvpn.net/openvpn/ticket/1161
 

4 hours ago, NaDre said:

For what it is worth, I have seen on Windows that routing metrics may be ignored in some instances.

Yes I think I've had encountered that on another occasion but I believe it was related to overriding an existing route with another route of lower metric, in other words de-prioritizing another route... iirc it seemed the old route was sorta cached and continued to be used for some limited time.
This will not be encountered if your application binds to a specific interface that leaves no other options though (like our case).
 

4 hours ago, NaDre said:

By the way, you said "only select programs will be able to use the VPN connection". It appears to  me that traffic splitting here is done based on the destination of the connection, not based on which program is making the connection. Or did I miss something?

Uh that's really hard to explain or to grasp because there're two different entities that do the same thing but at the same time they're really different.

Specific routes: you can always override an existing route with a more specific one. We actually only do this for the connection to the VPN server so it always runs via the public internet, no matter the settings (this in particular avoids stacking multiple VPN connections aka unintended multi-hopping).
Alternative routes: normally your system will always have a 'catch-all' 0.0.0.0/0 route. If we added an alternative route, it would only be used under the following circumstances:

• the new route has a more favorable metric (lower)
• the application explicitly binds to an IP that is only available to the second interface, thus forcing to use the new route

The second 0.0.0.0/0 route and binding to the second IP work in tandem. The traffic splitting is really done by the application requesting communication over the 2nd IP (the VPN interface).
That's what it looks like:

1. AirVPN-TAP network interface has your internal address as 10.20.30.42.
2. The application requests a new listening socket on 10.20.30.42:35361
   1. Now the application can only be reached via that IP address, i.e. only reachable via VPN. Like you can't even reach it via the localhost address: 127.0.0.1:35361. In fact you can have an entirely different service running on 127.0.0.1:35361, because it is not occupied.
3. If the application wants to connect to someone. It requests a connection from 10.20.30.42:35361 to <Target-IP:port>
   1. Since no other interface has an assigned IP of 10.20.30.42, the VPN interface is the only one up to consideration
   2. 0.0.0.0/0 via 10.20.30.1 (internal IP of VPN Server within the tunnel) says that any IP is reachable via VPN server
   3. Your OS routes that request via the VPN interface(tunnel) then. It is an entirely different story how the VPN itself is reached

You can try all of that out with curl and ifconfig.co. It's curl that decides which interface to bind to and ultimately where the packets will originate from.
Even if you have a 'kill switch' VPN, you can still override it with curl (or any malware could for that matter), just set your LAN IP to override the default route. You can (maybe?) fix it with a firewall or as I suggested in the guide: an intermediary device to force all traffic through the VPN (a virtual machine set to NAT mode should work, in that case the host OS will be that device).

Keep in mind, this comes quite handy in cases where you're rate-limited based on the IP address. You can use your home IP and your VPN IP simultaneously now: just instruct the program to use a certain IP. In case of IPv6 you get 4 IPs instead of 2. Use that hidden knowledge to your advantage Edited ... by guidance

[OpenSourcerer 1435]

2 hours ago, guidance said:

It's not available in the NetworkManager interface, maybe if you talk to OpenVPN directly it will work. But it's also written like this in the documentation:

For OpenVPN to be available in NetworkManager you need its OpenVPN plugin, package name is network-manager-openvpn in Debian/Ubuntu and networkmanager-openvpn in all other families.

[Foxtrod89 0]

Would you share vpn config? Mine is a big mess, can't fugure out why I'm getting 

'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])

[guidance 7]

On 5/22/2021 at 8:36 AM, Foxtrod89 said:

Would you share vpn config? Mine is a big mess, can't fugure out why I'm getting 

'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])

The options I've shown are really the only lines you need to add, don't overthink it and just test it with curl --interface to verify the public IP.
That is because this 'error message' in particular tells you that OpenVPN is correctly ignoring the networking routes pushed to us by the server (this is 'route-nopull'). In short: this is what it must show. Really, it's correct.

Though for completeness' sake, this is my complete log (redacted in a few places) and the config (auto-generated by AirVPN configurator + no-pull lines added).

Config:

client
dev tun
remote <AIRVPN SERVER IP> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
verb 3
explicit-exit-notify 5
rcvbuf 262144
sndbuf 262144
push-peer-info
setenv UV_IPV6 yes
remote-cert-tls server
comp-lzo no
data-ciphers AES-256-GCM:AES-256-CBC:AES-192-GCM:AES-192-CBC:AES-128-GCM:AES-128-CBC
data-ciphers-fallback AES-256-CBC
proto udp
key-direction 1


# NOPULL START
route-nopull
# "default"/"vpn_gateway"/"remote_host"/"net_gateway" are allowed placeholders. Since ipv6 has no other special words, use pushed "default"
# I SPECIFIED MY ROUTER IP EXPLICITLY: 192.168.69.1
# IF YOU DO NOT USE ANOTHER VPN THAT TAKES OVER ALL YOUR TRAFFIC, USE net_gateway
# net_gateway WILL BE AUTOMATICALLY DETERMINED AND WILL WORK IF YOU CONNECT THROUGH OTHER NETWORKS
# LIKE A PUBLIC WIFI
route remote_host 255.255.255.255 192.168.69.1
route 10.0.0.0 255.0.0.0 vpn_gateway
route 0.0.0.0 0.0.0.0 default 666
route-ipv6 ::/0 default 666
dev-node AirVPN-TAP

# MY OWN CUSTOM OPTION
link-mtu 1452
# END OF NOPULL

# THERE MAY FOLLOW THE BUNDLED CERTIFICATE FOR YOU

Log:

I have added a few comments for you to follow

2021-02-27 10:25:21 OpenVPN 2.5.0 <openvpn_verson> [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on ...
2021-02-27 10:25:21 Windows version 6.1 (Windows 7) 64bit
2021-02-27 10:25:21 library versions: OpenSSL 1.1.1h  ..., LZO 2.10
Enter Management Password:
2021-02-27 10:25:21 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25349
2021-02-27 10:25:21 Need hold release from management interface, waiting...
2021-02-27 10:25:21 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25349
2021-02-27 10:25:21 MANAGEMENT: CMD 'state on'
2021-02-27 10:25:21 MANAGEMENT: CMD 'log all on'
2021-02-27 10:25:21 MANAGEMENT: CMD 'echo all on'
2021-02-27 10:25:21 MANAGEMENT: CMD 'bytecount 5'
2021-02-27 10:25:21 MANAGEMENT: CMD 'hold off'
2021-02-27 10:25:21 MANAGEMENT: CMD 'hold release'
2021-02-27 10:25:21 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-02-27 10:25:21 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

== OPENVPN COMPLAINS DUE TO MY CUSTOM MTU OPTION, AIRVPN PUSHES/USES BAD MTU FOR ME
2021-02-27 10:25:21 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1330)
2021-02-27 10:25:21 TCP/UDP: Preserving recently used remote address: [AF_INET]<Public AirVPN Server Address IPv4>:1194
2021-02-27 10:25:21 Socket Buffers: R=[8192->262144] S=[8192->262144]
2021-02-27 10:25:21 UDP link local: (not bound)
2021-02-27 10:25:21 UDP link remote: [AF_INET]<Public AirVPN Server Address IPv4>:1194
2021-02-27 10:25:21 MANAGEMENT: >STATE:1616667921,WAIT,,,,,,
2021-02-27 10:25:21 MANAGEMENT: >STATE:1616667921,AUTH,,,,,,
2021-02-27 10:25:21 TLS: Initial packet from [AF_INET]<Public AirVPN Server Address IPv4>:1194, sid=00cc3139 c640d892
2021-02-27 10:25:21 VERIFY KU OK
2021-02-27 10:25:21 Validating certificate extended key usage
2021-02-27 10:25:21 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2021-02-27 10:25:21 VERIFY EKU OK
2021-02-27 10:25:21 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=<AirVPN's Server Certificate Name>, emailAddress=info@airvpn.org

== OPENVPN COMPLAINS DUE TO MY CUSTOM MTU OPTION, AIRVPN PUSHES/USES BAD MTU FOR ME
2021-02-27 10:25:22 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1452', remote='link-mtu 1558'
2021-02-27 10:25:22 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1330', remote='tun-mtu 1500'
2021-02-27 10:25:22 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 4096 bit RSA
2021-02-27 10:25:22 [<AirVPN's Server Name>] Peer Connection Initiated with [AF_INET]<Public AirVPN Server Address IPv4>:1194

== WHAT SERVER PUSHES TO US
2021-02-27 10:25:22 PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.26.124.1,tun-ipv6,route-gateway 10.26.124.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:ZZZZ:XXXX::YYYY/64 fde6:7a:7d20:167c::1,ifconfig 10.26.124.XXX 255.255.255.0,peer-id 0,cipher AES-256-GCM'

== WHAT IS IGNORED DUE TO ROUTE-NOPULL (I.E. ROUTES AND DNS). IT SHOWS UP AS WARNINGS/ERRORS, BUT THIS IS CORRECT
2021-02-27 10:25:22 Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
2021-02-27 10:25:22 Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
2021-02-27 10:25:22 OPTIONS IMPORT: timers and/or timeouts modified
2021-02-27 10:25:22 OPTIONS IMPORT: compression parms modified
2021-02-27 10:25:22 OPTIONS IMPORT: --ifconfig/up options modified
2021-02-27 10:25:22 OPTIONS IMPORT: route-related options modified
2021-02-27 10:25:22 OPTIONS IMPORT: peer-id set

== MY CUSTOM MTU IS ACTUALLY CORRECT, THANKS BUT NO THANKS
2021-02-27 10:25:22 OPTIONS IMPORT: WARNING: peer-id set, but link-mtu fixed by config - reducing tun-mtu to 1327, expect MTU problems
2021-02-27 10:25:22 OPTIONS IMPORT: data channel crypto options modified
2021-02-27 10:25:22 Data Channel: using negotiated cipher 'AES-256-GCM'
2021-02-27 10:25:22 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-02-27 10:25:22 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-02-27 10:25:22 interactive service msg_channel=356

== THIS SHOWS WHAT OPENVPN CONSIDERS YOUR DEFAULT GATEWAY (ROUTER) TO THE INTERNET
== IF YOU DON'T USE ANOTHER VPN SIMULANEOUSLY, USE net_gateway AND IT WILL BE AUTO-SELECTED
== IF YOU DO USE ANOTHER VPN, SPECIFY YOUR ROUTER IP MANUALLY AS PER GUIDE TO NOT ROUTE AIRVPN THROUGH ANOTHER VPN
2021-02-27 10:25:22 ROUTE_GATEWAY <default net_gateway as detected by OpenVPN aka your router>/255.255.255.0 I=19 HWADDR=00:11:22:33:44:55
2021-02-27 10:25:22 GDG6: remote_host_ipv6=n/a
2021-02-27 10:25:22 GetBestInterfaceEx() returned if=19
2021-02-27 10:25:22 GDG6: II=19 DP=::/3 NH=fe80::8
2021-02-27 10:25:22 GDG6: Metric=256, Loopback=0, AA=1, I=0
2021-02-27 10:25:22 ROUTE6_GATEWAY fe80::8 I=19
2021-02-27 10:25:22 open_tun
2021-02-27 10:25:22 tap-windows6 device [AirVPN-TAP] opened
2021-02-27 10:25:22 TAP-Windows Driver Version 9.24
2021-02-27 10:25:22 Set TAP-Windows TUN subnet mode network/local/netmask = 10.26.124.0/10.26.124.XXX/255.255.255.0 [SUCCEEDED]
2021-02-27 10:25:22 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.26.124.XXX/255.255.255.0 on interface {12345678-90AB-CDEF-1234-133769001234} [DHCP-serv: 10.26.124.254, lease-time: 31536000]
2021-02-27 10:25:22 Successful ARP Flush on interface [34] {12345678-90AB-CDEF-1234-133769001234}
2021-02-27 10:25:22 MANAGEMENT: >STATE:1616667922,ASSIGN_IP,,10.26.124.XXX,,,,,fde6:7a:ZZZZ:XXXX::YYYY
2021-02-27 10:25:22 IPv4 MTU set to 1399 on interface 34 using service
2021-02-27 10:25:22 INET6 address service: add fde6:7a:ZZZZ:XXXX::YYYY/128
2021-02-27 10:25:22 add_route_ipv6(fde6:7a:7d20:167c::/64 -> fde6:7a:ZZZZ:XXXX::YYYY metric 0) dev AirVPN-TAP
2021-02-27 10:25:22 IPv6 route addition via service succeeded
2021-02-27 10:25:22 IPv6 MTU set to 1399 on interface 34 using service
2021-02-27 10:25:28 TEST ROUTES: 3/3 succeeded len=3 ret=1 a=0 u/d=up
2021-02-27 10:25:28 MANAGEMENT: >STATE:1616667928,ADD_ROUTES,,,,,,

== EXPLICITLY ROUTE AIRVPN THROUGH ROUTER
2021-02-27 10:25:28 C:\Windows\system32\route.exe ADD <Public AirVPN Server Address IPv4> MASK 255.255.255.255 192.168.69.1
2021-02-27 10:25:28 Route addition via service succeeded

== EXPLICITLY ROUTE 10.0.0.0-10.0.0.255 THROUGH VPN (THE MASK HERE IS WRONG, I HAD IT CORRECTED IN THE GUIDE)
2021-02-27 10:25:28 C:\Windows\system32\route.exe ADD 10.0.0.0 MASK 255.255.255.0 10.26.124.1
2021-02-27 10:25:28 Route addition via service succeeded

== ANY IPv4 TRAFFIC IS ALLOWED THROUGH AIRVPN, BUT ONLY AS LAST CHOICE DUE TO METRIC
2021-02-27 10:25:28 C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 10.26.124.1 METRIC 666
2021-02-27 10:25:28 Route addition via service succeeded

== ANY IPv6 TRAFFIC IS ALLOWED THROUGH AIRVPN, BUT ONLY AS LAST CHOICE DUE TO METRIC
2021-02-27 10:25:28 add_route_ipv6(::/0 -> fde6:7a:7d20:167c::1 metric 666) dev AirVPN-TAP
2021-02-27 10:25:28 IPv6 route addition via service succeeded
2021-02-27 10:25:28 Initialization Sequence Completed
2021-02-27 10:25:28 MANAGEMENT: >STATE:1616667928,CONNECTED,SUCCESS,10.26.124.XXX,<Public AirVPN Server Address IPv4>,1194,,,fde6:7a:ZZZZ:XXXX::YYYY
2021-02-27 10:28:20 [<AirVPN's Server Name>] Inactivity timeout (--ping-restart), restarting
2021-02-27 10:28:20 SIGUSR1[soft,ping-restart] received, process restarting
2021-02-27 10:28:20 MANAGEMENT: >STATE:1616668100,RECONNECTING,ping-restart,,,,,
2021-02-27 10:28:20 Restart pause, 5 second(s)



== THIS IS WHERE THE PREVIOUS TUNNEL TIMES OUT BY OPENVPN (DUE TO INCORRECT INTERNAL IP) AND A RECONNECT IS INITIATED
== AFTER THE RECONNECT I DO GET FULL CONNECTIVITY
== I DO NOT KNOW IF THIS IS A BUG WITH MY OS+SOFTWARE OR A PECULIARITY OF THIS CONFIGURATION, BUT THIS IS NOT NORMAL.
== BASICALLY, GIVE IT 1-3 MINUTES TO CONNECT NORMALLY. ANY SOFTWARE THAT YOU HAVE BOUND TO ONLY USE THIS INTERFACE IS OK
== AND CAN BE STARTED EARLIER (NO CONNECTION LEAKING) BUT THAT SOFTWARE WILL HAVE TO RESTART CONNECTIONS AUTOMATICALLY
== TO CONNECT SUCCESSFULLY ONCE THE FULL VPN LINK HAS BEEN ESTABLISHED
== PREVIOUSLY NOT WORKING INTERNAL IP: 10.26.124.XXX
== CORRECTLY WORKING INTERNAL IP AFTER AUTO-RECONNECT: 10.26.124.CCC



2021-02-27 10:28:25 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-02-27 10:28:25 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2021-02-27 10:28:25 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1330)
2021-02-27 10:28:25 TCP/UDP: Preserving recently used remote address: [AF_INET]<Public AirVPN Server Address IPv4>:1194
2021-02-27 10:28:25 Socket Buffers: R=[8192->262144] S=[8192->262144]
2021-02-27 10:28:25 UDP link local: (not bound)
2021-02-27 10:28:25 UDP link remote: [AF_INET]<Public AirVPN Server Address IPv4>:1194
2021-02-27 10:28:25 MANAGEMENT: >STATE:1616668105,WAIT,,,,,,
2021-02-27 10:28:25 MANAGEMENT: >STATE:1616668105,AUTH,,,,,,
2021-02-27 10:28:25 TLS: Initial packet from [AF_INET]<Public AirVPN Server Address IPv4>:1194, sid=42c04644 3263e3c6
2021-02-27 10:28:25 VERIFY KU OK
2021-02-27 10:28:25 Validating certificate extended key usage
2021-02-27 10:28:25 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2021-02-27 10:28:25 VERIFY EKU OK
2021-02-27 10:28:25 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=<AirVPN's Server Name>, emailAddress=info@airvpn.org
2021-02-27 10:28:25 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1452', remote='link-mtu 1558'
2021-02-27 10:28:25 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1330', remote='tun-mtu 1500'
2021-02-27 10:28:25 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 4096 bit RSA
2021-02-27 10:28:25 [<AirVPN's Server Name>] Peer Connection Initiated with [AF_INET]<Public AirVPN Server Address IPv4>:1194
2021-02-27 10:28:25 PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.26.112.1,tun-ipv6,route-gateway 10.26.112.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:ZZZZ:XXXX::YYYY/64 fde6:7a:7d20:1670::1,ifconfig 10.26.112.CCC 255.255.255.0,peer-id 1,cipher AES-256-GCM'
2021-02-27 10:28:25 Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
2021-02-27 10:28:25 Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
2021-02-27 10:28:25 OPTIONS IMPORT: timers and/or timeouts modified
2021-02-27 10:28:25 OPTIONS IMPORT: compression parms modified
2021-02-27 10:28:25 OPTIONS IMPORT: --ifconfig/up options modified
2021-02-27 10:28:25 OPTIONS IMPORT: route-related options modified
2021-02-27 10:28:25 OPTIONS IMPORT: peer-id set
2021-02-27 10:28:25 OPTIONS IMPORT: WARNING: peer-id set, but link-mtu fixed by config - reducing tun-mtu to 1327, expect MTU problems
2021-02-27 10:28:25 OPTIONS IMPORT: data channel crypto options modified
2021-02-27 10:28:25 Data Channel: using negotiated cipher 'AES-256-GCM'
2021-02-27 10:28:25 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-02-27 10:28:25 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-02-27 10:28:25 Preserving previous TUN/TAP instance: AirVPN-TAP
2021-02-27 10:28:25 NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
2021-02-27 10:28:25 C:\Windows\system32\route.exe DELETE <Public AirVPN Server Address IPv4> MASK 255.255.255.255 192.168.69.1
2021-02-27 10:28:25 Route deletion via service succeeded
2021-02-27 10:28:25 C:\Windows\system32\route.exe DELETE 10.0.0.0 MASK 255.255.255.0 10.26.124.1
2021-02-27 10:28:25 Route deletion via service succeeded
2021-02-27 10:28:25 C:\Windows\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 10.26.124.1
2021-02-27 10:28:25 Route deletion via service succeeded
2021-02-27 10:28:25 delete_route_ipv6(::/0)
2021-02-27 10:28:25 IPv6 route deletion via service succeeded
2021-02-27 10:28:25 Closing TUN/TAP interface
2021-02-27 10:28:25 delete_route_ipv6(fde6:7a:7d20:167c::/64)
2021-02-27 10:28:25 IPv6 route deletion via service succeeded
2021-02-27 10:28:25 INET6 address service: remove fde6:7a:ZZZZ:XXXX::YYYY/128
2021-02-27 10:28:25 TAP: DHCP address released
2021-02-27 10:28:26 interactive service msg_channel=356
2021-02-27 10:28:26 ROUTE_GATEWAY <default net_gateway as detected by OpenVPN aka your router>/255.255.255.0 I=19 HWADDR=00:11:22:33:44:55
2021-02-27 10:28:26 GDG6: remote_host_ipv6=n/a
2021-02-27 10:28:26 GetBestInterfaceEx() returned if=19
2021-02-27 10:28:26 GDG6: II=19 DP=::/3 NH=fe80::8
2021-02-27 10:28:26 GDG6: Metric=256, Loopback=0, AA=1, I=0
2021-02-27 10:28:26 ROUTE6_GATEWAY fe80::8 I=19
2021-02-27 10:28:26 open_tun
2021-02-27 10:28:26 tap-windows6 device [AirVPN-TAP] opened
2021-02-27 10:28:26 TAP-Windows Driver Version 9.24
2021-02-27 10:28:26 Set TAP-Windows TUN subnet mode network/local/netmask = 10.26.112.0/10.26.112.CCC/255.255.255.0 [SUCCEEDED]
2021-02-27 10:28:26 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.26.112.CCC/255.255.255.0 on interface {12345678-90AB-CDEF-1234-133769001234} [DHCP-serv: 10.26.112.254, lease-time: 31536000]
2021-02-27 10:28:26 Successful ARP Flush on interface [34] {12345678-90AB-CDEF-1234-133769001234}
2021-02-27 10:28:26 MANAGEMENT: >STATE:1616668106,ASSIGN_IP,,10.26.112.CCC,,,,,fde6:7a:ZZZZ:XXXX::YYYY
2021-02-27 10:28:26 IPv4 MTU set to 1399 on interface 34 using service
2021-02-27 10:28:26 INET6 address service: add fde6:7a:ZZZZ:XXXX::YYYY/128
2021-02-27 10:28:26 add_route_ipv6(fde6:7a:7d20:1670::/64 -> fde6:7a:ZZZZ:XXXX::YYYY metric 0) dev AirVPN-TAP
2021-02-27 10:28:26 IPv6 route addition via service succeeded
2021-02-27 10:28:26 IPv6 MTU set to 1399 on interface 34 using service
2021-02-27 10:28:31 TEST ROUTES: 3/3 succeeded len=3 ret=1 a=0 u/d=up
2021-02-27 10:28:31 MANAGEMENT: >STATE:1616668111,ADD_ROUTES,,,,,,
2021-02-27 10:28:31 C:\Windows\system32\route.exe ADD <Public AirVPN Server Address IPv4> MASK 255.255.255.255 192.168.69.1
2021-02-27 10:28:31 Route addition via service succeeded
2021-02-27 10:28:31 C:\Windows\system32\route.exe ADD 10.0.0.0 MASK 255.255.255.0 10.26.112.1
2021-02-27 10:28:31 Route addition via service succeeded
2021-02-27 10:28:31 C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 10.26.112.1 METRIC 666
2021-02-27 10:28:31 Route addition via service succeeded
2021-02-27 10:28:31 add_route_ipv6(::/0 -> fde6:7a:7d20:1670::1 metric 666) dev AirVPN-TAP
2021-02-27 10:28:31 IPv6 route addition via service succeeded
2021-02-27 10:28:31 Initialization Sequence Completed
2021-02-27 10:28:31 MANAGEMENT: >STATE:1616668111,CONNECTED,SUCCESS,10.26.112.CCC,<Public AirVPN Server Address IPv4>,1194,,,fde6:7a:ZZZZ:XXXX::YYYY

 

Edited ... by guidance

[Foxtrod89 0]

Can't make feasible on macOS host.(bigsur) Not able to fetch IP address from VPN server to be exactly... Config's routing section exactly the same though! I heard there's some extra work with PF needs to be done on macOS hosts.

[guidance 7]

@Foxtrod89 Hm that's weird. In that case: connect normally, write down internal gateway (server) IP and the IP you got assigned and put it manually in the config? Obviously this means you would need one config per each server you want to connect to (no country configs). Good luck :P

[guidance 7]

TLDR: Windows will sometimes default the traffic through VPN when you have connection problems despite this config. It will get routed through VPN for like 20 minutes max. and then revert to default traffic via LAN router.

I'm putting this guide on hold until further notice due to a surprising behavior on Windows. Though is it really that surprising?
With this configuration the system thinks there're two equally valid network routes to reach the internet: via router (preferred due to low metric) and via VPN ('last choice' due to high metric).
To my surprise on Windows when there're intermittent lags/connection drops (actually momentary) the OS switches to using the undesired VPN route by default for traffic even though the main LAN connection persists at all times. I suppose this will not happen if your connection is rock solid and very stable.

If you wish to help investigate, here's what I did:
Cygwin/WSL. Results may differ between those, if you can record both simultaneously, it'd be useful. You need the Unix watch(1) command, for Cygwin it's part of "procps-ng" package.
Different console (terminal) windows:

1. watch -n 30 'ping 8.8.8.8 -n 3; curl --silent ifconfig.co; curl --silent -4 ifconfig.co; echo "expected: <My IPv6 IP> / <My IPv4 IP>"'

   every 30s ping and get current ipv6/4 address for the default route

2. watch -c -n 5 'route -4 print | grep -v "\.\.\." | tail -n +5'

   print all IPv4 routes (to see everything that's going on). Linux/Mac users that's the only thing you'd need to adapt

3. watch -c -n 5 'route -6 print | grep -v "\.\.\." | tail -n +5'

   print all IPv6 routes

I recorded them using OBS (screen capture) to see on video when/how it changes because at first I couldn't believe my eyes. Despite the routes not changing one bit, the default route chosen for IPv4 traffic changes! AND ONLY IPv4 TRAFFIC! Such a trash of an OS Windows is. I thought at first 'no, this is right, my connection drops for a moment and the system picks the working alternative route' - BUT why does only IPv4 change and not the IPv6 too? The logic should be the same... yet probably it isnt because even tracert/ping/route commands all have different implementations with regards to their IPv6 options.

People who used this in addition to another (primary) VPN are not affected due to how OpenVPN adds overriding routes. There're ways to adapt the above config to accomodate a fix, but it'd be a hacky solution to a problem that shouldn't exist to begin with. Edited ... by guidance

[guidance 7]

Changelog: Added Linux/nix-specific notes to the guide. The only missing part was the explanation for creation of custom TUN/TAP interfaces.
To repeat: The issue of a bouncing default gateway remains unsolved. Sometimes due to lag the default used gateway will switch from your router to the VPN. This is the built-in fail-over and options I tried on Windows didn't work. Your bound applications will never leave the VPN network though. I will edit this reply once I add the settings for Linux.

[flat4 79]

this is a great write-up

[maxandjim 2]

I've got a problem to solve along these lines. My Raspberry Pi4 runs an OpenVPN/Airvpn Client config file and works as a hotspot for eg 192.168.4.1/24 devices connected via wifi. It also routes the tunnel to an ethernet adaptor so various other devices (ethernet) can be VPN'd, but on a different subnet 192.168.10.10/24. It works good, sub 0.5ms internal pings and ethernet HD TV etc all excellent and using AIr DNS, getting Air IP's.

I can forward an airvpn port to a local port on my Pi4, like AirVPN port ***** to local :631 and view my CUPS admin page from the interwebs, works fine.

Question is how I go about viewing lets say my motioneye gui running on an ethernet device on my LAN ie 192.168.10.100? I can't forward a port within AirVPN because the 10.100 device isn't a client in its own capacity? I've reached that point in a learning curve where the brain hurts.

My ideas so far are to:

A: Run the other ethernet pi's as clients themselves, not sure if this would work, them being clients going through another client.
B: Change Pi4 to a server config though I suspect this may be a ground up rebuild which I don't want to do.
C Run a browser instance on eg port 88888 (is it doable?) on the Pi4, pointing at the motioneye on the other device, and map the AirVPN port forward to 88888 local
D Something else, possibly simple, that I've entirely overlooked?

Any help/advice appreciated 🙂

[guidance 7]

@maxandjim Think about the whole picture to understand the issue.
Raspberry Pi is connected to Air. This means port-forwards come through AirVPN and end up on the RPi itself (192.168.4.1/24 actually RPi's IP inside the VPN tunnel). Your RPi is like a router, when it gets an incoming connection, it doesn't know if the outsider wants to talk to the RPi or to someone else who's connected to RPi.
This means you must use iptables to forward a certain port to the device you want to respond. Forgive me I don't know the exact iptables commands, but it's along the lines of:
if destinationPort == (motioneye port)
and destinationIP == RPi VPN tunnel IP (10.x.x.x/32, the subnet it's in is /24)
then: NAT forward packet to IP 192.168.10.100.

I think IPv6 should work and route automatically if not denied by default. In any case, you enter the territory where Wireshark or any other network capture tool is your friend this smiley embodies possibly hours of searching and hair pulling. If it doesn't work, I suggest you open a different thread; incoming connections aren't affected by split-tunneling, only outgoing are.
PS: I hope the above command is correct in principle but if not, you'll have to look towards iptables & NAT reroutes.

[airjohns 0]

I'm trying to follow this guide, but it fails on the first step. I've downloaded openvpn client but there wasnt a bin folder there, so i installed eddie and even though there wasnt a bin folder there either, there was the tapctl file, so i ran it as follows and that's the error i get. Am I doing something wrong here?

C:\Program Files\AirVPN>tapctl create --name AirVPN-TAP
tap_create_adapter: DiInstallDevice failed
Error 0xe0000203
Creating TUN/TAP adapter failed (error 0xe0000203).

[NaDre 157]

1 hour ago, airjohns said:

I'm trying to follow this guide, ...
 

You might have better luck with this:

https://github.com/tool-maker/VPN_just_for_torrents/wiki/Running-OpenVPN-on-Windows-without-VPN-as-Default-Gateway

You add routing table entries to put the original default gateway back in effect (using a provided script - copy and paste). And then bind the torrent client to the VPN interface (or address) to have it use the VPN.

I have used this (I wrote the scripts there) for many years.
 

[airjohns 0]

18 hours ago, NaDre said:

You might have better luck with this:

https://github.com/tool-maker/VPN_just_for_torrents/wiki/Running-OpenVPN-on-Windows-without-VPN-as-Default-Gateway

You add routing table entries to put the original default gateway back in effect (using a provided script - copy and paste). And then bind the torrent client to the VPN interface (or address) to have it use the VPN.

I have used this (I wrote the scripts there) for many years.
 

Got it set up with those scripts in no time!
Thank you!

[tranquivox69 27]

Total newbie to Linux, setting up a machine for server-like activities. One thing I need to have is, using the AirVPN software for Linux, being able to select programs that use the VPN, while leaving everything else through my regular ISP connection. I use Linux Mint, is there a "for dummies" guide explaining how to do that? Or is what's in this guide the best I can find?

Thanks in advance.

[Friction7090 0]

Greetings, I recently switched to airvpn from mullvad and I'm struggling with something.
I have a printer/scanner connected to the router, we all share it in the house and since I installed eddit I have been unable to get it to work. I believe I set things correctly.
I checked the local ip of the printer on my router's settings and added said IP to the routes section as outside the tunne, I did the same with a raspberrypi that I use to mount a drive to multiple devices with sshfs but now I can't connect to either, I can connect to the raspberrypi only through the vpn since I gave that one a airdns address.
So, what did I miss? Where should I double check to make sure everything is in order?

[SkyFyx 0]

On 4/5/2023 at 5:58 PM, tranquivox69 said:

Total newbie to Linux, setting up a machine for server-like activities. One thing I need to have is, using the AirVPN software for Linux, being able to select programs that use the VPN, while leaving everything else through my regular ISP connection. I use Linux Mint, is there a "for dummies" guide explaining how to do that? Or is what's in this guide the best I can find?

Thanks in advance.

Hi, 

Have you figured out how to do split tunneling with Eddie on linux? Because like you, I'm looking for resources but can't find or understand anything. 

I only know how to add a port on the site and I don't even know how to configure it.

Thanks in advance if you come by again.

[squishfab 0]

is there a guide for doing this with WireGuard?

Edited ... by squishfab
words

[tranquivox69 27]

On 7/21/2023 at 8:00 PM, SkyFyx said:

Hi, 

Have you figured out how to do split tunneling with Eddie on linux? Because like you, I'm looking for resources but can't find or understand anything. 

I only know how to add a port on the site and I don't even know how to configure it.

Thanks in advance if you come by again.

Sorry for the late reply. Yes, I did find a solution. Have a look at the discussions starting from here, between user NaDre and me:
It's quite long and a bit "stream of consciousness-y" but in the end it led me to a working solution where I can use the VPN for torrent clients (those supporting the binding to a specific interface, that is) and Firefox (using a proxy server I installed, as discussed in that thread).

[ms2738 5]

Try and try and can't get this working the way I want on my Mac,  It seems like it SHOULD be easy, the VPN range is 10.x and I can can bind Qbittorrent to the TUN adapter of the VPN, but when I disable the default redirect Qbitorrent just stops even bound to the right TUN and IP.

[guidance 7]

@ms2738 Your reply shows me that based on your understanding of the topic you are half way there. If you want to continue with this, you will need to see the differences in the routing table the OS has with vs without the default redirect option. For testing see the curl command from above.
Unfortunately the redirect/gateway detection is already acting weird on Windows and that's why I hoped exact instructions like this would help.