Staff

Hello! The AirVPN integration is kindly maintained by GlueTun developer. In brief, servers information is retrieved from the servers,json file which is updated several times a year. When starting up, Gluetun merges the hardcoded list and the contents of servers.json, preferring newer data and including any custom entries marked to be kept. For more details and a more accurate description please see here: https://deepwiki.com/qdm12/gluetun/6-server-management At this moment, while we're writing this message, the servers in Amsterdam have not yet been added. You can wait for the next update, or you may add them manually, by abiding to the json format. Alternatively you can point directly, through the proper environment variable, to the correct entry-IP address of the server you wish to connect to. In such cases you find all the information you need on the server status page https://airvpn.org/status and by generating a configuration file with the Configuration Generator. Here's an example for Vindemiatrix, only for WireGuard connections. This block must be inserted in the correct position: study the file structure to quickly understand. Make sure to edit the file while no container is running. { "vpn": "wireguard", "country": "Netherlands", "region": "Europe", "city": "Amsterdam", "server_name": "Vindemiatrix", "hostname": "nl3.vpn.airdns.org", "wgpubkey": "PyLCXAQT8KkM4T+dUsOQfn+Ub3pGxfGlxkIApuig+hk=", "ips": [ "94.228.209.212" ] }, You then need to restart the container(s) in order to merge the current list with the edited one. Do not rebuild the complete list otherwise your manually added servers will be lost unless protected by "Keep": true line/flag (inside the server definition). Kind regards

Hello! Hold on @Tech Jedi Alex, you hit the mark. You were just misled by this: 0777 is for a directory, but for data files the default is 0666, here's why the user ends up with 644: For the reader, if the umask is 022, the newly created file by root will get 644 (rw-r--r--) (the complement of 666 with 022 in octal) which causes the first problem. So that's why /sbin/bluetit doesn't have x even though it does in the extracted package. It doesn't matter that the original bluetit file has 755, the umask starts from 666. cp in the original script lacks the -p option so this problem should get resolved by your change with install (it should be solved even by adding "-p" to the cp command, or an additional chmod of course). It looks like a long time installation script issue that went always and strangely unnoticed. Noted down for a fix in the next release or a package hot fix, we'll see. Apparently there is another problem too but maybe it's not related to Suite's installation, we'll keep following the thread. Kind regards

Hello! We're very glad to inform you that three new 10 Gbit/s full duplex servers located in Toronto (Ontario), Canada, are available: Castula, Chamukuy and Elgafar. 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/Castula https://airvpn.org/servers/Chamukuy https://airvpn.org/servers/Elgafar/ Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

Hello! GlueTun consults an xml file (usually providers.xml) for this purpose that is not maintained by AirVPN but by the good will of the developer who kindly integrated GlueTun with AirVPN. You need to keep the file up to date in general, and sometimes you have to wait for an update to have this file reflect all the servers that are periodically added or modified. If you check the file format you can also edit it manually to add specific servers you need, in case they are missing. The real time server monitor provides you with all the information you need to update the providers.xml file. Kind regards

Original message by @Pit61 . It updates the setup for FreshTomato based routers. Here is my working Open VPN config on a Netgear R7000 with Fresh Tomato:

Hello! Thanks for having pointed out, typo was fixed. The correct expiration date is 2026-01-08 as stated in the first part of the announcement. Kind regards

Thank you very much. For the readers: the key information here and other threads where the problem could be resolved swiftly is that it does not matter how you configure it: Plex will always listen to port 32400 of the VPN interface. Therefore, AirVPN's port "re-mapping" function comes handy. Once you choose a random port for your Plex server on your AirVPN account port panel, fill the "Local" field with "32400". Reach the Plex server from the Internet on the port remotely forwarded and the VPN server will take care to forward the packets to port 32400 of your local VPN interface. Kind regards

Thank you for your great feedback! In the USA we have five different, independent from each other providers that guarantee a decent diversification. Servers are located into 11 different datacenters. Kind regards

Hello! We're very glad to inform you that a new 10 Gbit/s full duplex server located in Los Angeles, California, is available: Revati. 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. Revati 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 , by clicking the server name. Direct link: https://airvpn.org/servers/Revati Do not hesitate to contact us for any information or issue. Kind regards & datalove AirVPN Staff

Hello! You should modify several settings (add the mentioned host directory as an allowed mount entry point, disable apparmor limitations to load kernel modules, allow read access by the container to the proper modules) that can pose a security problem. You can find everything you need on the documentation but in your case consider to build the WireGuard kernel module locally, inside the container, if you wish to maintain strict isolation and complete compatibility. Upgrading servers is a constant process but configuration files have not changed in the last months. Please consider that now OpenVPN pushes IPv6 routes and configuration no matter what. The source of the problem could be that IPv6 is disabled in the container and if so you should enable it or filter out anything related to IPv6 coming from the OpenVPN server. To do so, please see here: https://airvpn.org/forums/topic/26548-linux-ip-6-addr-add-failed/?do=findComment&comment=72069 If the problem persists, allow us to examine the Hummingbird log taken after a connection attempt with OpenVPN has failed. Kind regards

Hello! Note: Suite versions older than 2.0.0 do not support WireGuard. Note: do not try to access Debian 13 kernel modules from a Debian 12 container. It's possible that the WireGuard kernel module is not properly loaded in your Debian 13 LXC container, even though Debian 13 host includes the module. LXC containers can be restricted from accessing kernel modules even if they're available on the host. Please make sure that the container has access to the network related kernel modules by checking your LXC configuration file. If this is not possible or anyway you want to avoid it, then you need to ensure that WireGuard's kernel module is available inside the container. WireGuard kernel module (wireguard.ko or wireguard.ko.xz) should be in the following directory: /lib/modules/$(uname -r)/kernel/drivers/net/wireguard If the problem persists, can you please send us the output of the commands: uname -a lsmod | grep wireguard ls /lib/modules/$(uname -r)/kernel/drivers/net/wireguard Kind regards

@noonereturnsthesame Hello! A possible problem we can infer from the piece of log you kindly published is a conflict with Proton. Since we see that a Proton interface is up, it's possible that you're trying (even unintentionally) to use both AirVPN and ProtonVPN at the same time. This is possible but only with special configuration (multiple routing tables and virtual interfaces, or more trivially with virtualization) and in general it will cause conflicts. Can you please make sure that, when you are going to use AirVPN, ProtonVPN related programs and services have been already stopped? If you ascertain the above and the problem persists, please generate and send a full system report, please see here to do it: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

Hello! You didn't need that, you could have used a configuration file generated by the Configuration Generator, provided that you could access at least one of the various AirVPN web sites. For those persons who can't access any of the AirVPN mirrors we have an easy workaround solution that is not published because it must be tailored almost individually, please contact the support team. Technically, the reason is that the AirVPN bootstrap servers and/or the protocol used to communicate with the bootstrap servers is/are blocked by some Russian ISPs as reported in the dedicated thread on blocks in Russia. Yes, definitely, and this is planned. It is being implemented and you will see it in an imminent Eddie 4 version, maybe already in beta 2 or RC 1. Eddie will read locally the user data when bootstrap servers are unreachable. So you will need to access a VPN server only one time through a configuration file. Once in the VPN, the block toward the bootstrap servers are bypassed and Eddie will download and store locally the file it needs for future usage. It will remain stored as long as you don't force its deletion. Side (obvious) note: the mentioned user file is related only to the user you logged in, so it will not be valid when you try to log a different user in to the service Not true. Eddie Android edition can be used as a generic client so anything a generic client can do, Eddie can do too. In this case generate a proper configuration file and have Eddie connect by reading that configuration file. Kind regards

Hello! It could be sufficient and currently it is indeed sufficient from Russia and China, where you bypass blocks with the backward compatible H parameters. The H parameters could become in the future an additional weapon against evolving blocking techniques. Kind regards

Hello! Correct, the I parameters are meant for Custom Protocol Signature (CPS). When you connect to a WireGuard based server you must preserve backward compatibility. Jc, Jmin, Jmax, I1-I5 parameters remain free (within the mentioned constraints), while you must set: S1 = 0 S2 = 0 H1 = 1 H2 = 2 H3 = 3 H4 = 4 Various persons (as well as our original post) report also that you can mix H parameters, but they must be different from each other, and each H must be included between 1 and 4. Kind regards