Staff

@nocturnaltabernacle Hello! It might be an MTU size issue. By default, on Linux and FreeBSD, WireGuard might set a 1420 bytes MTU size, which is too big for some networks. Shrink it to 1320 or even 1280 bytes (the minimum accepted value) and test again. In order to change wg interface MTU size on your BSD system, please edit the wg configuration file with any text editor and add the line: MTU = 1320 in the [Interface] section. Kind regards

@BatteriVoltas Hello! Please feel free to open a ticket to get thorough support. In the ticket please state whether you get error 110 or 111 when you test from AirVPN web site port tester. As a preliminary check, please make sure that Deluge settings related to UPnP and NAT-PMP are all disabled and that no firewall (running in the same machine where Deluge runs too) interferes with packets to and from Deluge. A quick reference guide to check other settings: https://airvpn.org/faq/p2p/ Kind regards

Hello! Because it's not mandatory. You can open a ticket from an account which does not have any e-mail address. Kind regards

Hello! All the tickets (by customers) are normally answered in 2-8 hours during business days. During Sunday and other special days (Christmas, New Year's Day...) tickets are answered in 12 hours on average, and in 24 hours in the worst case.. Support service is not outsourced therefore we have total control over the support system and best expertise is guaranteed. Account DARR1 never opened a ticket. Furthermore, the e-mail address linked to DARR1 never sent any e-mail to "support@airvpn.org". Please feel free to open a ticket at your earliest convenience. Alternatively, write to support via e-mail (from the e-mail address linked to the account). Kind regards

Hello! We're very glad to inform you that a new 10 Gbit/s server located in Alblasserdam (the Netherlands) is available: Dalim. 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 and 47107 UDP for WireGuard. Dalim 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 and 4096 bit DH key not shared with any other VPN server. You can check the status as usual in our real time servers monitor: https://airvpn.org/servers/Dalim Do not hesitate to contact us for any information or issue. Kind regards and datalove

Hello! You have many options since we support Raspberry Pi machines thoroughly. 1. You can rely on the AirVPN Suite, which is available for 32 and 64 bit ARM processors. A legacy version is available as well: https://airvpn.org/linux/suite/ Pick a version according to the system you're running (32 or 64 bit OS) and if in doubt do not hesitate to specify your exact system and contact us. Examples: if you have the new Raspberry Pi OS 64 bit, download the 64 bit version. If you run some Raspbian 32 bit OS (deprecated) pick the 32 bit legacy version. The AirVPN Suite provides you with a stand alone binary, or a daemon and a client: just pick the solution that you like most as all the components are lightweight. User manual available here: https://airvpn.org/suite/readme/ 2. If you have the option to install Mono package and you can afford some bigger RAM footprint, you can consider Eddie ARM edition, which offers a fully featured GUI that the Suite does not provide for: https://airvpn.org/linux/eddie/ Also consider that Eddie integrates WireGuard, while the Suite currently doesn't (a new version supporting WireGuard is imminent, stay tuned). 3. Last alternative option is simply running a native WireGuard or OpenVPN client. In such cases, just follow the instructions for Linux related to the "native" clients. Our Configuration Generator will generate all the files those clients need, according to your preferences. Kind regards

@FlyawayRavage Hello! The --air-server option requires an argument which is the exact server name, all is unknown with --air-info. The --air-key-list is stand-alone, you must not add --air-info. The --air-info --air-country combination also accepts continent names, and the special keyword earth. In your case, when Bluetit is connected to some VPN server, it ignores all of those commands and simply tells you the status. This behavior might be changed in the next version, as it might be confusing. What you probably want is (while Bluetit is disconnected from the VPN): goldcrest --air-list --air-country all Kind regards

Hello! We have experienced a serious kernel panic problem apparently reported here: https://github.com/OpenVPN/ovpn-dco/issues The reported kernel crashes which we also experienced are fearsome, because when they occur all users (even WireGuard ones of course) are disconnected, machine control is lost, and a reboot via IPMI or hard power cycle is required. Before allowing something to run as a kernel part on a production server for all of you, that something must behave more properly. We will keep testing and searching for a stable setup, and of course we also hope in imminent bug fixes. We will keep you informed. Of course rolling out OpenVPN 2.6 without DCO is an option, but we would prefer to migrate directly to OpenVPN with DCO, instead of having to do it in two different steps. Kind regards

Hello! We're very glad to announce a special promotion on our long term Premium plans for the end of Summer or Winter, according to the hemisphere you live in. You can get prices as low as 2.06 €/month with a three years plan, which is a 70% discount when compared to monthly plan price of 7 €. If you're already our customer and you wish to stay aboard for a longer period, any additional subscription will be added on top of already existing subscriptions and you will not lose any day. Please check plans special prices on https://airvpn.org and https://airvpn.org/buy All reported discounts are computed against the 7 EUR/month plan. Kind regards & datalove AirVPN Staff

@litef00t Hello! Please upgrade (if you haven't already done so) to Eddie Android edition 3.0, where the autostart at boot procedure has been greatly enhanced to increase compatibility both with old Android versions (5.1) and the latest 12 and 13. If necessary please see here: https://airvpn.org/android/eddie/apk/tv/ Kind regards

@ddrahos Hello! For clarity's sake we now replace "device" word with client "certificate". You do have different client certificates but you have all the sixteen ports linked to a single certificate named "Server", so all of your *.airdns.org names will always resolve into the exit-IP address of the last VPN server the devices using the "Servers" certificate connect to. If you wish that a different name resolves into a different IP address, let the 2nd device use a different certificate, and link to that certificate the set of ports that the 2nd device needs. This gives you the freedom to have different names, each one resolving correctly to the proper exit-IP address of the VPN server you want, at the small price of dividing ports for each device. Feel free to elaborate about which other questions the new system raises, we'll try to answer if possible. Kind regards

Hello! Please click "Contact us" button on the top right corner of the web pages, or write an e-mail to support@airvpn.org Kind regards

Hello! It's already implemented, and even in a more flexible way. Since a few months ago linking a name to a specific port is no more pro-forma only, provided that you have multiple "devices" and you configure different ports to link to different "devices". You can link the port to a specific "device", and a specific DDNS to one or multiple ports. In this way you have an even more flexible and comfortable system. For each device, each name of yours will resolve into the exit-IP address of the last VPN server to which you connect through that specific "device". In the port panel just select the "device" you want for that port, provided that the port is enabled. You can do so in the combo box just under the enable/disable toggle. If you use the same "device" on multiple devices which connect at the same time, and/or you have your remotely forwarded ports configured to "all devices", you will experience the behavior reported by @ddrahos , i.e. you will fall back to the a behavior which allows full backward compatibility with the previous system. Kind regards

@zsam288 Hello! Yes, but on most residential lines you must switch to OpenVPN and also force TCP; WireGuard is blocked on every line (as far as we know), while UDP is sometimes blocked, sometimes heavily shaped. Our Eddie Android app recognizes problems and switches modes in an attempt to bypass blocks, but only when it works with OpenVPN (WireGuard has only one possible working mode...) so you need to manually switch to OpenVPN. Also, you may save time by directly forcing TCP and port 443, otherwise the app might not find the correct connection mode. For example, if UDP is heavily shaped but not blocked, the app will never switch to TCP by itself, because an UDP connection is finalized successfully. [In Eddie Desktop edition you can change connection mode in the "Preferences" > "Protocols" window.] Have a nice journey and a nice stay! Kind regards P.S. To stay on the safe side, and since Tor might be blocked on some lines, bring with you a small list of Tor obfuscated bridges IP addresses that you can configure in Tor Browser + Orbot (Android apps) in case of emergency.

Hello! Please check whether the problem is related to https://www.macwheeler.com/windows-10-office-365-cannot-connect-over-openvpn-fixed - the workaround is easy. You may also test a WireGuard connection to potentially discern whether it's an OpenVPN-specific problem, as described in the above linked article, or not. If you run Eddie, the Air software client, you can switch to WireGuard in the "Preferences" > "Protocols" window. Kind regards

In this case you're most probably fine: if we interpret correctly the data set you provided the behavior is expected. The "pinger" has always remained disabled (as far as we remember) when Eddie is connected to the VPN. Maybe you had some release with a bug? The unexpected behavior in this case would be Eddie that "pings" the VPN servers even while the system is connected to one of them. Kind regards

@tranquivox69 Hello! Probably everything is fine. The "pinger" is disabled when the system is connected to some VPN server, according to the logic that the round trip times for Eddie connection purposes make sense only between the client node and the VPN servers, and not between client+VPN server and the all other VPN servers. https://github.com/AirVPN/Eddie/blob/de5c1ebb91030dc654a4cd3de81bfa8225982400/src/App.CLI.Common.Elevated/ping.cpp public bool GetCanRun() { bool canRun = true; // Logic: Can't ping when the connection is unstable. Can't ping when connected to server. if (Engine.Instance.IsConnected()) { canRun = false; } else if (Engine.Instance.IsWaiting() && (Engine.Instance.WaitMessage.StartsWithInv(LanguageManager.GetText("WaitingLatencyTestsTitle")) == false)) canRun = false; return canRun; } If you want the pinger to be active even while the system is connected to the VPN you can set canRun to true (here above), even when Engine.Instance.IsConnected() is true. When the pinger is active you should not see in Windows "ping.exe" processes (if we're not mistaken). See also: https://github.com/AirVPN/Eddie/blob/de5c1ebb91030dc654a4cd3de81bfa8225982400/src/App.CLI.Common.Elevated/ping.cpp and https://github.com/AirVPN/Eddie/blob/de5c1ebb91030dc654a4cd3de81bfa8225982400/src/Lib.Core/Jobs/Latency.cs Kind regards

@jahoolala Hello! Does anything change if you add the following custom directive: mssfix 1280 To add it, from Eddie's main window select "Preferences" > "OVPN Directives", type the above directive in the custom directives field, click "Save". Re-start a connection to apply the change. If the problem persists let us see a system report. https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-%E2%80%93-heres-what-to-do/ Kind regards

@Bertin Hello! Please try to side load it: https://airvpn.org/android/eddie/apk/tv/ Kind regards

@doncammne Hello! Please open a ticket, because we don't see any delay at the moment. Kind regards

Use https://www.startpage.com - it will query Google Search and return to you the exact Google Search reply. Kind regards

@p9974839 Hello, we also see a sea of green. We still have 11000 Mbit/s free (full duplex), or if you prefer 22000 Mbit/s free total, in Canada which are never used by anyone, so the infrastructure is greatly oversized. Yellow means that you still have at least 1000 Mbit/s free on the server. Look at the very screenshot you sent us: it shows that you have plenty of choices in Canada on poorly used servers: 15 servers offer more than 1 Gbit/s (more than 500 Mbit/s full duplex)! Check our previous message as well. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s full duplex server located in Berlin (Germany) is available: Taiyi. 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 and 47107 UDP for WireGuard. Taiyi 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 and 4096 bit DH key not shared with any other VPN server. You can check the status as usual in our real time servers monitor: https://airvpn.org/servers/Taiyi Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team 

@kbps Hello! Not really, because the feature is included in our WireGuard setup since the very beginning, when we offered WireGuard as a beta feature some years ago. If you want more information, please see here: https://www.wireguard.com/protocol/ In this way we can implement a recognized as quantum-resistant cipher if needed, according to our customers request . You may ask why don't you pick one PQ cipher right now? You already configured the most part! We have excellent reasons not to do so right now: It's premature. In spite of the hype, currently a quantum computer doesn't work for any practical purpose to break even the weakest encryption algorithm and in the last 40 years or so the expected date to have a working quantum computer capable to perform something more than basic arithmetic have been shifted decade after decade. Research has progressed more slowly than ultra-optimists expected. To break RSA 2048 in a reasonable time a rigorous simulation shows that you need at least 1 million (probably up to 10 millions) of physical qubit (you need probably at least 10'000 logical qubits, and due to the astronomically high error rate of qc, to rely on them you need ~ x100 physical qubits). Nowadays the biggest companies are struggling to beat 433 logical qubits qc (IBM promised 1000 logical qubits machine within the beginning of 2024). It hits performance. Some promising PQ ciphers use 64 KB or larger public and private keys and you will notice a performance hit if you have a Gbit/s line and you're used to the high performance our infrastructure is normally capable to provide. The load both on server and client will increase. It exposes our customers to unnecessary risks. Post-quantum algorithms are far less well-studied. Any PQ algorithm, that today is considered safe, can be compromised tomorrow by "classical" computes.. It happened already to SIKE, which before the spectacular fall was considered one of the strongest and best algorithm for Diffie-Hellman key exchange in a post-quantum world. It was cracked in a matter of hours a few months ago with a program running in a single thread of a single core of a desktop CPU. SIKEp434 was broken within approximately an hour, SIKEp503 cracking required 2 hours, SIKEp610 8 hours and SIKEp751 21 hours. See also https://www.securityweek.com/nist-post-quantum-algorithm-finalist-cracked-using-classical-pc/ So, we have the infrastructure ready to add a PQ cipher, when and above all if it will be necessary, without exposing you to risks of cracking by classical computers and/or "performance hit for nothing". Kind regards

Hello! Please see here: https://airvpn.org/forums/topic/49876-new-feature-dns-block-lists/ Kind regards