Staff

Hello! We're very glad to inform you that Hummingbird 2.0.0 Release Candidate 3 is now available for macOS, both for Intel and M1/M2/M3/M4 based systems. The links to the latest RC 3 and the main changes have been updated in the first message of this thread. This new version is linked against the latest OpenVPN3-AirVPN library version and improves gateway detection when used in WireGuard mode. Kind regards

Hello! We're very glad to inform you that AirVPN Suite 2.0.0 Release Candidate 3 for Linux is now available. The original post is updated to show the new download URLs. The important improvements over RC 2 are: bug fixes Blutetit: added run control directive networkcheck (please see the included user's manual readme.md) Bluetit: removed run control directive airvpnconnectivitycheck (superseded by networkcheck directive) gateway is set in case it was not provided at construction time Special note for firewalld users Please read here, it's very important: https://airvpn.org/forums/topic/70164-linux-network-lock-and-firewalld/ Please note that compatibility with Debian 10 and its derivatives, that reached end of long term support and end of life on June 2024, is lost even for the legacy version, mainly because the Suite is now C++20 compliant. The legacy version remains suitable for Debian 11 and its derivatives. Kind regards

Hello! We're very glad to inform you that two new 10 Gbit/s full duplex servers located in Frankfurt, Germany, are available: Adhil and Fuyue. They will replace 1 Gbit/s servers Intercrus, Serpens, Tucana and Veritate, which will be decommissioned on 2025-07-31 as they run on hardware and lines that show first signs of inadequacy after a year of extraordinary userbase growth. The AirVPN client will show automatically the new servers; if you use any other OpenVPN or WireGuard client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637, 47107 and 51820 UDP for WireGuard. They support OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the status as usual in our real time servers monitor : https://airvpn.org/servers/Adhil https://airvpn.org/servers/Fuyue Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

Hello! Please note that if Eddie crashes no leak occurs because Network Lock is a set of firewall rules. Kind regards

Hello! This is by design to avoid permanent lock out on remotely accessed machines while allowing non-VPN traffic when wished. Please also note that the article is wrong in telling that there's a leak during a system reboot even when network lock is enabled: the leak may occur only if the Network Lock has not been engaged, for example if you have not started the AirVPN software. On Linux systems you also have the option of setting a persistent network lock with Bluetit daemon, a component of the AirVPN Suite. As soon as the daemon starts it enforces the network lock, no matter whether a connection is started or not. If you have a systemd based Linux distribution, please note that the asinine systemd init startup is not deterministic and this is of course not our responsibility. Therefore you can't be sure when Bluetit will be started, regardless of the priority you wish. If you need permanent blocking firewall rules surviving reboots even when the VPN software is not running the solution is straightforward: set permanent firewall rules as explained in various articles (a recent one is here https://airvpn.org/forums/topic/69097-permanent-kill-switch-for-eddie-client) or follow the suggestion included in the very same article you linked. Be aware that this setup is problematic on remotely accessed machines. Kind regards

Hello! Thank you very much for your tests! Confirmed, the new OpenVPN3-AirVPN library crashes at disconnection as we incautiously dragged in a dirty modification from the main branch. Problem identified and addressed. Kind regards

Hello! No, we do not work with them, luckily! We have different providers in Germany and new servers will be added soon with new address ranges. Probably the block is aimed at various datacenters to prevent not only usage of publicly known VPN for consumers, but also home made VPN or simply SSH access to proxy to the Internet. Kind regards

Hello! The ZeroTier network interface could be the cause of the problem. Please try to disable the interface and make sure that no ZeroTier VPN etc. related software is running, then try again and check whether the problem gets resolved or not. Kind regards

@Pwbkkee Hello! After extensive debugging we noticed that Bluetit does not crash, but WireGuard does. Please note that in your setup the following option on the bluetit.service file you created: ProtectKernelModules=true prevents Bluetit from loading firewall and WireGuard kernel modules, which are needed respectively for Network Lock and WireGuard proper functioning. The following one: RestrictNamespaces=true prevents traffic splitting. The absence of ConfigurationDirectoryMode= with ConfigurationDirectory=airvpn implies a change of permission in /etc/airvpn (by default 660) with subsequent security problems that must be seriously considered, otherwise the unit can not work in general. Running Goldcrest as a service must also be carefully considered and whenever possible Goldcrest should work as it was designed for, i.e. as a client, with the asynchronous mode in your case. Goldcrest keeps all the standard streams (stdin, stdout and stderr, including TTY access) open, whereas Bluetit does not, as it is a real daemon, not a systemd service, which is only a pale daemon surrogate if you want to be kind, or a fake if you want to call a spade a spade. Therefore running Goldcrest with root privileges by systemd is another security flaw that must be pondered. Other directives could introduce additional problems, but we haven't investigated deeply all of them, we just want to point you toward the main problems and explain the issue you experience. The whole setup introduces instability, causes WireGuard and OpenVPN3-AirVPN library to crash, lowers security and prevents important Bluetit features including Network Lock, so proceed only if you know exactly what you're doing and always consider the instability that you cause especially on WireGuard and OpenVPN library. Kind regards

Hello! After the hardware replacement the server is apparently working very well. Should you find any anomaly do not hesitate to warn us and/or update this thread. Kind regards

@name8828 Hello! Please read here: https://airvpn.org/faq/port_forwarding We kindly invite you and everyone to read manuals and FAQ answers before posting. Kind regards

Hello! The problem has been finally isolated. From the provider customer service, just a few hours ago: "We have located the issue with the cabling, and have asked to [...] swap cables and ports around. This will correct the issue. [...] We expect this work to be completed within 24hrs". Kind regards

Hello! Sulafat is now up. The problem was that some of its IP addresses remained null-routed after a flood attack. Kind regards

Thank you, under investigation. screen or any other multiplexer is unnecessary thanks to the async mode (option --async). We will keep you posted. Kind regards

@Pwbkkee Hello and thank you for your tests! Please post at your convenience the complete Bluetit log to let us investigate. Suite components are designed after a client-daemon architecture, where Bluetit is a real daemon (not a generic service, a real daemon) and Goldcrest is a client. Your setup is odd and poses a few problems, since you turn a client into a service and you try to have a service-service arch. What is it that you can't do with current architecture that forces you into this sort of aberration? For example, in your case if you want Bluetit to connect by itself you don't need an auxiliary service, you can do it through the run control directives in bluetit.rc file and you would have a connection as soon as Bluetit comes up, instead of being forced to wait for yet another service to come up. Kind regards

Hello! Yes, a problem with the network interface arose, we're sorry. We are bringing the server down. We will work with the datacenter technicians to resolve the issue. Kind regards

Hello! We're very glad to inform you that a new 10 Gbit/s full duplex server located in Toronto (Ontario, Canada), is available: Kornephoros. The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637, 47107 and 51820 UDP for WireGuard. Kornephoros supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the status as usual in our real time servers monitor . Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

Hello! Thanks, this is a matter for GlueTun developer, we would recommend that you contact him and explain the problem. Please note that in the compose file you set a variable with the = char, not with : . Kind regards

Hello! When VPN_SERVICE_PROVIDER is set to airvpn the optional environment variables deciding the end point are: SERVER_COUNTRIES: Comma separated list of countries SERVER_REGIONS: Comma separated list of regions SERVER_CITIES: Comma separated list of cities SERVER_NAMES: Comma separated list of server names SERVER_HOSTNAMES: Comma separated list of server hostnames https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/airvpn.md If you feel that this is a bug or unexpected behavior (we see your point: WIREGUARD_ENDPOINT_IP should not be ignored when a non-generic VPN provider is selected, as it apparently happens in your case), the matter should be reported to GlueTun's developer. Please keep in mind that GlueTun is fully compatible and well integrated with AirVPN but it is not developed by AirVPN so every issue should be reported properly also here: https://github.com/qdm12/gluetun-wiki/issues Kind regards

Hello! Your setup is fine and we can reach your listening software through the port that you remotely forwarded. If you need more ports please make sure to pick a free port (the proper tools on the bottom of your AirVPN account port panel will let you find free ports) or just let the system pick a free one for you by leaving the "Port number" field blank and clicking the '+' button. Kind regards

Hello! Thank you! No reason apart from obsolescence of the announcement. Build is anyway for M1. Kind regards

I am also interested in this, but I didn't get it working. Could you please provide more details on how to set it up? A few snippets for the Powershell would be very helpful. Allowing DHCP traffic out, seems to be an default rule with Windows 10. Hello! Something like this will do the trick, starting from a clean status and Windows Firewall enabled. Make sure you operate from a Powershell with administrator privileges. The rules will survive at reboot. You must adjust your local network address/netmask (change 192.168.0.0/16 and fe80::/10 if necessary). Do not proceed if you don't understand exactly every single command; instead, get documented first. netsh advfirewall firewall add rule name="Allow DHCPv4" protocol=UDP dir=out localport=67,68 action=allow netsh advfirewall firewall add rule name="Allow DHCPv6" protocol=UDP dir=out localport=546,547 action=allow netsh advfirewall firewall add rule name="Allow Local IPv4 Network" protocol=TCP dir=out remoteip=192.168.0.0/16 action=allow netsh advfirewall firewall add rule name="Allow Local IPv6 Network" protocol=TCP dir=out remoteip=fe80::/10 action=allow netsh advfirewall firewall add rule name="Allow Localhost Outbound" dir=out action=allow remoteip=127.0.0.1 netsh advfirewall firewall add rule name="Block All Other Outbound Traffic" dir=out action=block protocol=any You may also consider to backup the rules and enable them only when needed, instead of keeping them permanent. Check your system manual to do this. Kind regard

Hello! Yes, perfectly possible. Just configure your application(s) to connect to your proxy and use it/them while the system is connected to the VPN. Kind regards

@Hitotsume Hello! Traffic splitting on a destination address basis is not implemented in the Suite and as a consequence exceptions to Network Lock are not available from the options: you would need to add specific rule(s) after the lock has been enforced. However, in your case this is not necessary as Network Lock already allows local networks. Furthermore, the Suite may take care to avoid VPN traffic tunneling into the local network even with WireGuard (default behavior). The behavior can be set through the specific option allowprivatenetwork as you might already know from the manual: * allowprivatenetwork (yes/no) Control how the local and private network traffic can pass through the Network Lock. When disabled, only VPN traffic is allowed through the Network Lock. When enabled local and private network traffic, as well as VPN traffic, is allowed to pass through the Network Lock. Default: yes Please note that WireGuard support and configuration of Network Lock behavior for local network are implemented on AirVPN Suite 2.0.0, currently available as Release Candidate 2: https://airvpn.org/forums/topic/66706-linux-airvpn-suite-200-preview-available/ AirVPN Suite 2.0.0 also implements traffic splitting on an application basis. Although not required in your specific case, since from your description it sounds like you need to connect to sshd only locally, in various scenarios per app traffic splitting may be more useful and/or a valid replacement of traffic splitting on a destination basis. In your case, if you need to have sshd traffic outside the VPN tunnel (i.e. you explicitly want to leak SSH traffic outside the VPN tunnel so that you can reach sshd from the Internet without pointing to AirVPN server addresses and without AirVPN remote port forwarding) it's preferable to just split ssh traffic (read the 2.0.0 user's manual to achieve in a very simple way this purpose if it is necessary). Kind regards

Hello! AirVPN Suite 2.0.0 RC 2 is now out and the error you found has been addressed. Can you please test again and report back at your convenience? Kind regards