Staff

@lowdrag Hello! It is an expected behavior when the system is connected to the VPN. The logic behind this is that computing round trip times from a VPN server would be detrimental for a correct server choice. However, if the system is disconnected from the VPN then this is an unexpected behavior: please test Eddie 2.24.x and check whether the same issue persists or not. Kind regards

Hello! The Kaspersky VPN adapter is causing a critical error. Please see here for a very quick solution: https://airvpn.org/forums/topic/56643-stuck-in-a-broken-route-never-connects/?do=findComment&comment=225323 Kind regards

@KingBletsoe Hello! A preliminary checklist: please make sure that the listening program is really running and listening to the correct port, and that it is started only after the VPN connection has been established if a bind option is available in the listening program settings please make sure that the program binds to the VPN interface and not to the physical network interface please make sure that no firewall rule blocks incoming packets to the listening program. You need to check while the system is connected to the VPN as some firewall tools change rule set according to the network type the system is connected to Kind regards

Hello! Please see here: https://airvpn.org/forums/topic/57025-dns-leak-when-wireguard-configuration-in-gluetun-with-qbittorrent-truenas-scale/?do=findComment&comment=227861 Kind regards

@555VPN Hello! The ca.crt expires in 2121. You can use the Configuration Generator to download and import any certificate. Your user.crt expires in 2033. Maybe you're watching some old certificate. Kind regards

Hello! It can mean that the port is "disabled", although the linked device is connected to some VPN server. The new switch "Enable" (on/off), available on each forwarded port in the AirVPN account panel, has been added recently and offers more flexibility. If you get "No ports open", instead, it means that the device linked to the port is not connected to any VPN server. Kind regards

Hello! Normally the changes are applied in a matter of minutes and they do not require re-connections, the forward rules are "hot swapped". However, your description hints at an undue delay, we will investigate. In order to speed up the change, if a similar problem re-surfaces, please disconnect and re-connect your system to the VPN server(s). Provided that your forwarded port(s) are enabled for all the "devices" of your account, that the forward rules are applied for all the various VPN interfaces, and that you know which exit-IP address your service is reachable on, the multi VPN configuration is not a problem. If you find that port forwarding works with a "single VPN" configuration, but stops working with a multi-VPN setup, you need to check the above again. No, this is not a cause for concern. Just keep in mind that without VPN DNS you can't use the AirVPN DNS based blocking system and the geo-routing system. Kind regards

We see you managed to solve the problem, welcome back! Kind regards

Hello! Excellent. The Configuration Generator puts the following directive in the wg .conf file: MTU = 1320 while Eddie 2.21.8 doesn't (Eddie 2.23 and higher versions do). It's possible that 1320 bytes is a better MTU for your network. You can now tweak this value in small increments (e.g. 1330, 1340...) to find the optimum MTU for performance. Each time you edit the wg.conf file (using any text editor), remember to stop and restart WireGuard for the change to take effect. Kind regards

Hello! Very glad to know it. Eddie 2.23 and older versions "Automatic" mode is OpenVPN in UDP, always. Eddie 2.24 and newer versions select what the manifest tells (currently WireGuard). WireGuard offers higher performance and efficiency, and a few privacy issues which are mitigated in our system. Please see here for an overview: https://airvpn.org/faq/wireguard/ Kind regards

@FriedTofu527 Hello and welcome aboard! Yes, as you can also see from the top users "speed" 700 Mbit/s is not unusual in AirVPN, but mainly with WireGuard and not OpenVPN. The best performance so far obtained in the infrastructure is around 1.1 Gbit/s on ideal conditions (no traffic shaping by ISP, good peering, at least 2.2 Gbit/s free on the server), with WireGuard and its interface MTU varying from 1320 to 1420 bytes. Perhaps you are comparing WireGuard with OpenVPN. Please switch to WireGuard to make a comparison on a level playing field. We share a lot of common providers and similar hardware, but not all, so please make sure that you test various servers in various locations in order to maximize the likelihood of good peering between your ISP transit provider and ours. For a more specific support please specify your Operating System name and version. If you run Eddie Desktop edition you can switch to WireGuard in the following way: from Eddie's main window select "Preferences" > "Protocols" uncheck "Automatic" select a line with WireGuard, for example WireGuard port 51820. The line will be highlighted click "Save" and restart the connection to apply the change Unfortunately Eddie 2.21.8 does not support MTU change for WireGuard, while this parameter is frequently crucial. If you don't get satisfactory performance you can try different MTU sizes with Eddie 2.24.x. Please see here to download it: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ With Eddie 2.24.x you can change MTU in the Preferences > WireGuard window. Kind regards

Hello! On top of the previous message we have checked your account and please note that you forwarded only one UDP port. Please check: if your listening program expects TCP packets (too) you must forward accordingly. If necessary you can change the listening protocol from your remote inbound port panel. The Protocol combo box, which is available on each port, can be set back to TCP+UDP (default setting) anytime. Kind regards

Hello! The cause of the problem and its solution are described here: https://airvpn.org/forums/topic/56657-cant-connect-to-anything/?do=findComment&comment=225418 Kind regards

@Cefiko Hello! Apparently UDP or OpenVPN is blocked. Please check any packet filtering tool, both on your router and system, and make sure that they do not block UDP. Also test WireGuard. It works in UDP too, so you can discern whether the block is against UDP in general or not. In order to switch to WireGuard: from Eddie's main window select "Preferences" > "Protocols" uncheck "Automatic" select a line with WireGuard (for example WireGuard port 58120). The line will be highlighted click "Save" If you find no packet filtering tool blocking UDP and WireGuard fails too, it's possible that the block comes from your ISP. In this case try to switch to OpenVPN, protocol TCP (you can do it again from the aforementioned window). Kind regards

@flyinryan62161 Hello! The problem can be caused by an unstable line or an inappropriate MTU. Please make sure that your router firmware and your network interface driver are both up to date. If you connect your device to your router via WiFi try to get a stronger signal and change channel properly. If you connect via cable, please test a replacement Ethernet cable. If you connect your device to to the VPN via WireGuard test small MTU sizes, starting from 1280 bytes. If you connect via OpenVPN over UDP, try to add the mssfix 1280 directive or switch to TCP. Should you need more specific support on points 3 and 4, please specify your Operating System name and version as well as the software you run to connect to AirVPN servers. Kind regards

@motomike Hello! In general, the problem you are experiencing is caused by the fact that the intersection set between the automatic connection server selection set and the server whitelist is empty. In your case, this may happen because you are in Japan, you have whitelisted Japanese servers, but you have kept Eddie from connecting to your own country's servers. You can work around the issue by either selecting a specific server to connect to (in the "AIRVPN SERVER" view) or by disabling Settings > AirVPN > Forbid quick connection to connect [to] servers in my country Kind regards

Hello! This remarkably good guide should help you: https://nguvu.org/pfsense/pfsense-port-forward/ It is focused on AirVPN remote inbound port forwarding for torrent clients but it can be very handy for any other listening program. 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. Promotion expires on 2024-03-26 UTC. Kind regards & datalove AirVPN Staff

Hello! We're very glad to inform you that two new 10 Gbit/s servers located in Alblasserdam (the Netherlands) are available: Menkent and Piautos. 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 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. The servers 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 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/Menkent https://airvpn.org/servers/Piautos Do not hesitate to contact us for any information or issue. Kind regards and datalove

Hello! From the documentation we think that SERVER_HOSTNAMES variable must contain hostnames (we infer therefore the FQDN (Fully Qualified Domain Names) we use), while SERVER_NAMES must contain the internal AirVPN names (for example Xuange) that you find in the mentioned JSON file as well as in the servers monitor: https://airvpn.org/status We also think that you need to valorize only one variable between the mentioned, optional ones, in order to avoid ambiguity or conflicts about the end point(s) to connect to. Kind regards

Is it possible for you to delete my account keys etc. for me? Hello! In theory AirVPN management can do it, yes. Please note that in this moment you have only one key, if it gets deleted you will be cut out from the VPN until you create a new key. We would recommend that you manage your keys by yourself: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ For any further support on the matter (on top of the community support here) please do not hesitate to open a ticket. Kind regards

Hello! We can confirm that the Configuration Generator works just fine as usual. Please select the proper key you desire on the CG page otherwise the CG will default to the first one and then remember to set it in the Gluetun configuration. The configuration generated by our CG is also consistent on what you wish, as it contains only the Xuange IP address. The IP addresses considered by Gluetun are not taken from the generated configuration file, but from the servers addresses included in the servers.json file, as far as we can see from Gluetun's documentation. We also see (again from the documentation) that you need to set the proper variables if you want to force Gluetun to connect only to specific areas or servers: 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 See also https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/airvpn.md Please remember that Gluetun is not an AirVPN software, therefore if our explanation is not enough you could get better answers from Gluetun developer. Kind regards

Hello! Please follow this guide: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Kind regards

Hello! Assuming that your NAS is not omniscient, it must have found the entry-IP addresses of Kajam and Crater in some configuration file, please check. However, another option is that someone else is using your account fraudulently, although from your description that's very unlikely as the ghost connections appear whenever your NAS tries to connect. Please go ahead, change your AirVPN account password AND renew all of your keys, just in case. Kind regards

Hello! Eddie Desktop edition stores client keys locally and updates them only when the account logs in to the bootstrap servers. Since you renewed a key recently, the old key was no more valid, but Eddie kept using it. By logging out and logging back in, with "Remember me" option disabled, you caused Eddie to re-download your keys and you solved the situation. Kind regards