Staff

Hello! Yes, it is related to OpenSSL library (1.1 is now deprecated and perhaps not available anymore in Mint). Please upgrade to Eddie 2.24.6 and also upgrade your OpenVPN package in your Mint distribution: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ Kind regards

Hello! This is due to how your client software picks the destination server. In the thread original message you mentioned Eddie. It lets you build a white list of servers or countries according to your connection preferences, respectively in the "Servers" and "Countries" window. Kind regards

Hello! Currently not, we're sorry. A new Eddie beta version will be out in the near future anyway. Kind regards

Hello! Do you experience this problem on Netherlands servers only (but please test the 10 Gbit/s ones too, Dalim, Menkent and Piautos in the NL), or on other European countries as well? Kind regards

Hello! Excellent! Consider that Eddie 2.21.8 includes very old WireGuard code, while the new 2.24.6 features an up to date one. Furthermore, when you test WireGuard native app, the VPN interface MTU is set to 1320 bytes because of our Configuration Generator directive, while Eddie 2.21.8 leaves default WireGuard size (usually 1460 bytes) which is not suitable in some networks. Eddie 2.24.x sets by default 1320 bytes MTU, and offers the option to modify it. AirVPN offers routed private networks built over transport layer protocol UDP (and, with OpenVPN, TCP too). The ISP can not tamper, forge or wiretap/sniff the content of the tunnel, but can enforce limitations (such as de-prioritization and other shaping methods) directly on the transport layer protocol. However, since you have 500 Mbit/s throughput when in the VPN and 600 Mbit/s when outside the VPN, this is probably not the case. A performance hit due to routing (because of the obliged hop, the VPN server) and other overhead (wrapping, encryption...) are physically unavoidable. If your peak is 600 Mbit/s without VPN, 500 Mbit/s inside the VPN is just fine in our opinion. Kind regards

Hello! Please ignore the previous answer, DNS is not the root of the issues. The first problem is related to the bootstrap access attempted by Eddie with a direct IP address. HTTP access without FQDN is sometimes not allowed in various networks. Please test Eddie 2.24.6 which tries bootstrap servers even with domain names, not only through IP addresses. The 2nd problem is that UDP seems blocked: please check any tool that might be blocking either OpenVPN or UDP, both on your Mac (including tools like LittleSnitch) and your router (on it, please disable for testing purposes any traffic management / QoS / filtering-mangling tool). To download Eddie 2.24.6 beta version please see here: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ If any problem persists, please send us the system report as recommended by the previous message. Kind regards

Hello! Please test again with ufw disabled to quickly discern whether an ufw custom rule is the "culprit". From a terminal enter the following command: sudo ufw disable You can later re-enable ufw if needed with sudo ufw enable Kind regards

Hello! According to the datacenters, this is a consequence of heavy flood attacks which compel the IP transit provider to null route specific IP addresses. We are assessing the situation. Kind regards

Hello! While the OpenVPN performance you report in macOS is unfortunately typical, the WireGuard performance should be much higher, provided that you are in a network that does not interfere with UDP. Please test Eddie 2.24.6 (on the M2 machines please make sure to download the optimized version for ARM 64 bit, important!) with WireGuard. Tune different MTU values for the WireGuard network interface. You can modify it on Eddie's "Preferences" > "Protocols" window. Each time you change MTU, please make sure to re-start the connection, in order to apply the change on WireGuard. Eddie 2.24.6 download instructions: https://airvpn.org/forums/topic/57401-eddie-desktop-224-beta-released/ The aforementioned program is beta software but it has been extensively tested, even by the Mac community, and a stable version should be released in a matter of days. It's important that you don't stay with Eddie 2.21.8 for performance reasons because it includes old WireGuard software and it does not allow you to modify WireGuard interface MTU. Kind regards

Hello! if the answer to the important previous question by OpenSourcerer is no, and in particular when the performance gap involves even transport layers such as TCP and UDP, it's not an infrequent experience. The optimization of the Linux TCP/IP stack is definitely superior, and when you bridge a Linux VM to the network interface you get rid of (you bypass it completely) Windows TCP/IP stack. A similar occurrence takes place when you create a FreeBSD VM in bridge mode, in a Linux host: although the network interface driver can be the same (FreeBSD ports a lot of drivers, including network card ones, from Linux) the FreeBSD VM networking shows lower round trip times and higher throughput than the host. Kind regards

Hello! Yes, it is possible in integer multiples of 5 connection slots per user. Please open a ticket or write to support@airvpn.org and our sales department will make you an offer according to your request. Kind regards

Hello! If you're running Eddie, a plausible explanation is that you white listed Metallah only. Please check "Show all" on the "Servers" window to see all the servers and adjust your white and/or black lists. Kind regards

Hello! After the problem occurred, please send us the output of: sudo journalctl | grep bluetit If you wish to test with ufw disabled: sudo ufw disable Kind regards

Version 2.24.6 (Wed, 08 Jan 2025 16:23:32 +0000) [change] [all] ISO 3166 break, changing "Taiwan, Province of China" into "Taiwan, Republic of China" [change] [all] New bootstrap endpoint [bugfix] [all] Bootstrap emergency urls fix [bugfix] [macOS] WireGuard issue [bugfix] [all] Minor fixes If no other serious issues arise, this version will be released as stable within a few days. The remaining minor issues (IP Exit, Speed Chart, etc.) are under investigation and will be fixed in the next version. Thank you.

Hello! It looks like an architecture error. Can you please check whether you have installed the correct package? Please make sure you download the proper package for your OpenSUSE architecture (x86-64, aarch64 etc.). Kind regards

Hello! Area domain names records are updated every 2-5 minutes but remember that TTL is 1 hour, so you can expect that a TTL respectful DNS updates cached records on average after 30 minutes. On our authoritative servers, us3.vpn.airdns.org did not resolve to Sarin entry-IP address 3 immediately after the packet loss was detected by the monitoring system. We're investigating the problem on Sarin. Kind regards

Hello! A possible solution may come by relying on the areas (country or continent) domain names offered by AirVPN. By using the general area name that resolve into the specific entry IP addresses of all the servers in that area you randomize and rotate the connections for each name. If the mentioned names are not flexible enough consider your own fully qualified domain names, five for example, each one resolving into a pool of VPN server entry-IP addresses according to your needs and preferences. Kind regards

@colorman Hello! Please test AirVPN Suite 2.0.0 beta 2 and let's move to the following thread if you experience the same (or any other) issue: https://airvpn.org/forums/topic/56704-linux-airvpn-suite-200-beta-available/ Kind regards

Yes! You're welcome. Kind regards

Please re-read the previous message because in the meantime we have found out that Netcup enforces traffic shaping against UDP, so you will never be fine with Netcup, and we have edited the message accordingly. Switch to WireGuard safely, the privacy problems with WireGuard are irrelevant for p2p, anyway they are mitigated by our system and you can also re-generate your key anytime to change VPN IP address. Kind regards

Hello! Netcup does enforce traffic shaping, and exactly against UDP, so you had better drop this service. Liteserver.nl does not mention officially traffic shaping against UDP, but on the forums you can find many issues with it reported by customers (only UDP). Assuming that traffic shaping is not enforced by liteserver.nl, a common reason for this error on virtual servers is the MTU size of the VPN Interface. Please try a smaller one through MTU option in WireGuard (you should test WireGuard before anything else). On the WireGuard's configuration file [Interface] section our Configuration Generator already adds MTU = 1320 which is good for most networks. If that's not enough please try also 1280 bytes. You can edit the profile with any text editor. Of course test only from liteserver.nl as Netcup is not suitable. In Eddie 2.24.x beta you can modify WireGuard interface MTU in "Preferences" > "WireGuard" window. Kind regards

Hello! Microsoft has confirmed that the April 2024 security updates (KB5036893 in particular) for Windows 11, Windows 10 and Windows Server have introduced bugs that cause various problems related to VPN (all protocols, including the pre-installed IPsec). A reported problem is that multiple VPN interfaces appear on affected systems as they accumulate at each session. The bugs should have been fixed with the latest updates: can you please make sure that your Windows system is up to date, just in case the problem is caused by the mentioned update? Kind regards

Hello! The performance you get is good, especially if you consider that you have packet errors when you connect over UDP. The fact that you get much better throughput on a specific port with the same protocols hints to traffic shaping by the ISP. The setup is safe provided that you add some measure against traffic leaks, please make sure that you enable Network Lock if you run AirVPN software. On top of that, you may also consider to bind the torrent software (if a bind option is available in your torrent program settings) to the VPN interface you mentioned. Kind regards

@Bokika 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! The most common reasons for what we see on the log, when UDP is not blocked by the ISP, are: Windows Defender blocking Eddie and/or OpenVPN traffic a traffic management / firewall tool on the router blocking UDP Please check and also consider to switch to WireGuard (you can do it in Eddie's "Preferences" > "Protocols" window). In case you ascertain or suspect that your ISP blocks UDP, you can switch to OpenVPN over TCP (again in "Preferences" > "Protocols" window). Kind regards