Staff

Hello! Today we're starting AirVPN 14th Birthday celebrations with big discounts on longer term plans. From a two servers service located in a single country providing a handful of Mbit/s, the baby has grown up to a wide infrastructure in 23 countries on four continents! AirVPN is now one of the only three major consumers' VPNs which are still independent, i.e. not owned by big corporations with multiple fields interests, interfering in editorial publications or intersecting with products or services in conflict with privacy protection. Ever since we celebrated the past 13th birthday, AirVPN focused on a comprehensive infrastructure enhancement consisting of: line and server expansion to accommodate the significant customer growth. The infrastructure is now capable of delivering up to 694,000 Mbit/s CPU and network interface upgrades on all four continents where we operate in order to further stabilise and consolidate actual bandwidth availability thorough rewrite of remote inbound port forwarding logic to avert impending port exhaustion. The new implementation will be unveiled soon far reaching improvements to the "behind the scenes" infrastructure (backend servers) through hardware upgrades and targeted software optimisation On the software side, all AirVPN applications and libraries are still free and open source software released under GPLv3. The development of traffic splitting features on an application basis, already available in AirVPN Eddie Android and Android TV edition, has been implemented on the AirVPN Suite for Linux. The OpenVPN3-AirVPN library has undergone a remarkable round of bug fixes and improvements, while the WireGuard library is now fully supported by the Suite. 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. Check the promotional prices here: https://airvpn.org/buy Promotion will end on June the 12th, 2024 (UTC). Kind regards and datalove AirVPN Staff 

@183aTr78f9o Hello! Please keep us posted and let us know, when you manage to reproduce the problem, what happens with the delay. It's not a solution we recommend because it can expose to leaks but the outcome may provide some insight. We're working on a different approach but we still can't reproduce the problem unfortunately, so it's too early to say whether or not the different approach will be effective. Different options for different tasks, even if partially overlapping, nothing too unusual. Kind regards

Hello! Please try the following procedure to resolve the problem: run Eddie on Eddie's main window uncheck "Remember me" log your account out log your account in (you'll need to re-enter your AirVPN credentials) try again a connection Kind regards

Hello! We're almost there: the 14th birthday celebrations will begin between the 27th and the 28th of May! Stay tuned! Kind regards

Hello and thank you for your tests! Excellent. Kudos to the new WireGuard library too. In the unit file targets you can see that systemd must start Bluetit only when the network is up (Wants=network-online.target). Bluetit also waits some more time for a valid gateway, see here: The above log entry seems to confirm that systemd is right and the network is really up but of course the fact that the network is up does not guarantee that the system's upstream router has a valid Internet connection. If the router does not have Internet connectivity, the incident wouldn't be a systemd or bluetit fault. We will investigate. In which distribution do you experience this? OK. By starting the connection with Goldcrest you may rely on the conn-stat-interval n option, where n is in seconds (please consult the user's manual for more details). You may also consider async for more tasks: the new asynchronous mode adds some interactivity, please check the new manual. However conn-stat-interval is not available in bluetit.rc. Thus, if you don't start a connection via Goldcrest, your approach is the way to go at a first glance. We'll consider your suggestion. Thanks again, keep testing! Kind regards

Hello! All of those "test_suite_*" tests are related to mbedTLS library suite. Let's wait for the maintainer's reply, or you can rely on the official repository. Note that we are going to move your and our messages on to the AirVPN Suite 1.3 thread in the next hours, because this is the thread dedicated to 2.0.0 public testing. Direct link: https://airvpn.org/forums/topic/56375-linux-airvpn-suite-130-available/ Kind regards

Hello! mbedTLS does not support x509. It's not needed by the Suite but maybe the linker enters the error state anyway, or maybe the mbedTLS libraries and include files are misaligned in your system. Can you please try with OpenSSL (which is the default setting)? Please set SSL_LIB_TYPE variable to OPENSSL: SSL_LIB_TYPE=OPENSSL in the following scripts: https://gitlab.com/AirVPN/AirVPN-Suite/-/blob/master/build-bluetit.sh?ref_type=heads https://gitlab.com/AirVPN/AirVPN-Suite/-/blob/master/build-bluetit-static.sh?ref_type=heads Kind regards

Can XMPP use forwarded ports on airvpn servers? I'm not aware of any setting that allows XMPP to use specific ports for calls. Hello! XMPP is a protocol. Clients implementing the protocol may let you specify listening ports which become indispensable for specific needs. In Pidgin you can do it in "Preferences" > "Network" > "Ports" > "Manually specify a range of ports to listen to". The other option "Enable automatic router port forwarding" is probably based on UPnP, so it must be disabled when you want to run Pidgin in the VPN. Kind regards

Hello! At a first glance UDP seems blocked but this block could be a consequence of the following interface picked by Eddie for OpenVPN: . 2024.05.22 22.01.11 - Using WinTun network interface "ProtonVPN TUN (ProtonVPN Tunnel)" Please try this and check whether the problem gets resolved: https://airvpn.org/forums/topic/56643-stuck-in-a-broken-route-never-connects/?tab=comments#comment-225323 If the problem persists after the above, please make sure that no Proton software is running concurrently (you must run only one VPN client at a time to avoid conflicts). Kind regards

Hello! The AirVPN's symmetric-like NAT makes STUN unsuitable, we're sorry, but in our infrastructure you can directly rely on the inbound remote port forwarding feature, so you can avoid an external STUN server. However, in your specific XMPP case, probably you will need anyway a TURN server. For example, with Pidgin (a client which implements XMPP) you can enable audio and video behind VPN without STUN but you will need a TURN server, according to the documentation, if we understand correctly. For the readers, please be careful with STUN as it may cause traffic leaks outside the VPN tunnel and disclose your "real" IP address if Network Lock is disabled. Typical uses of STUN are in browsers (with WebRTC) and SIP. Kind regards

Hello! We're still gathering information from various sources, therefore this is only a provisional answer. At the moment: OpenVPN over SSH and OpenVPN over SSL, to various ports except port 53, work WireGuard to port 51820 works on a limited set of servers. Unfortunately reports on this subject contradict each other about working servers so we can't say for sure which ones. UPDATE: multiple confirmations that WireGuard to port 51820 works on various servers, but not all of them access to bootstrap servers is blocked therefore you can't use Eddie Desktop or Android edition, or the AirVPN Suite integration, but you will need configuration files. UPDATE: we have new reports confirming that "secret" bootstrap servers DO work. You will obtain them by opening a ticket only from your valid AirVPN account to generate configuration from the Configuration Generator it's crucial that you can access one of our web sites. Currently they seem all accessible configuration files can be used with Eddie Android edition, Hummingbird, OpenVPN and WireGuard native clients, and Eddie Desktop edition through the external provider support option OpenVPN in tls-crypt mode over TCP to port 443 (connect to entry-IP address 3 to have this mode) works but only towards a small amount of servers (please test as many as you can) NEW circumvention option: please check this message: https://airvpn.org/forums/topic/59479-block-vpn-in-russia/?do=findComment&comment=237288 Kind regards

@zimbabwe Please open a ticket, the support team will tell you something interesting. Kind regards

Hello! It is possible that it's something caused by an ancient bug affecting various browsers and reported (on Android too) about 15 years ago: https://issuetracker.google.com/issues/36906622 or something related to mime types. In some rare cases this issue has been correlated to download managers as well. In iOS, for this specific task please use Safari, Chrome or Opera (without download manager extensions, if necessary), which are not affected by that (or similar) bug and can download files from the CG properly. If you decide to try and run WireGuard, you may also avoid downloading a file. You can consider to use a computer and shoot (on the computer monitor) the QR code rendered by our Configuration Generator to import the WireGuard configuration file into your iOS device. Kind regards

@perryaj Hello! You must not renounce to HTTPS. Explanation and solution has been provided by @OpenSourcerer in the first answer to the OP on this thread, please see here: https://airvpn.org/forums/topic/55424-nextcloud-server-behind-airvpn-problem-with-ssl/?do=findComment&comment=214209 Kind regards

Hello! By enabling Location Services your device sends location information (including wireless access point information, cellular tower information, and precise GPS location if available) to Microsoft. It will also allow apps to use their device’s location and location history to deliver location-aware services and disclose your location to third-party entities. Frequently, this behavior is exactly what must be avoided when connected to a VPN for privacy purposes. It may weaken significantly the anonymity layer. Kind regards

Hello! Windows can be configured to set time zone automatically according to the presumed location of the device. One of the factors to determine the location is the geo-location of "your" public IP address, which may be correct or wrong. The feature was added in November 2022 and has been repeatedly reported as buggy or not working at all in Microsoft support forums. The configuration can be managed in Settings > Time & Language > Date & Time. Kind regards

Hello! Please open a ticket at your convenience for this request. Very glad to know it and thanks for the additional information. Kind regards

@ogvickmackie Hello! Please check this: https://airvpn.org/forums/topic/58289-openvpn-certificate-has-expired/?tab=comments#comment-231319 If the problem persists, please generate and send a system report: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

@johannawellick Hello! We have seen from past reports that Radmin VPN causes the UDP block you are experiencing and which seems the reason of the problem. Can you please disable Radmin VPN and test again? We infer that you have that VPN active as the following interface is up: "Radmin VPN (Famatech Radmin VPN Ethernet Adapter)". Kind regards

Hello! That's defined on the Plex settings. In your specific case this is not relevant because you have the remote port *2866 forwarded to your VPN interface port 32400, so port *2866 never comes into play in your system and everything works. You don't need any modification. Kind regards

@johannawellick Hello! Can you please include a system report generated by Eddie just after a connection attempt failed? https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do/ Kind regards

@macuser2 Hello! Can you please test Eddie 2.24 beta version and check whether or not the problem persists? https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Kind regards

Hello! Can you please try again and report back? Kind regards

Hello! Thank you very much for your tests! We're very pleased to receive confirmation that this version solves those problems. Network Lock does not survive, but it is re-enforced before any new socket can be created, so no leak occurs. This is exclusively up to systemd: apart from writing correctly the suspend and resume unit files there's nothing else we can do, we're afraid. Kind regards

Hello! We have found a problem with WireGuard in one USA server, Polis. Perhaps when you experienced the problem, us3.vpn.airdns.org resolved into Polis entry-IP address. We have resolved the problem on Polis. Can you please try again now? If you experience the problem please note the specific server and let us know. Kind regards