Staff

Hello! Some preliminary considerations: https://airvpn.org/forums/topic/56989-can-the-10g-full-duplex-servers-operate-at-nearly-or-full-bandwidthcapacity/?do=findComment&comment=228405 Also, the choice is not hard coded. The connection mode picked when "Automatic" is selected may now be driven by the bootstrap servers' manifest file. We would gladly welcome feedback on the current WireGuard choice as well. Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.24 beta. It is ready for public beta testing. How to test our experimental release: Go to download page of your OS Click the button Switch to EXPERIMENTAL Download and install This is a new version of Eddie Desktop (Windows / Linux / MacOS). We know there is still 2.21.8 as stable, and 2.22.x and 2.23.x series never reached the stable version. We hope that this version 2.24.x will be tested and reach a stable release. Internally (in terms of development and code) it represents a significant step forward for us: the CLI editions are compiled with dotnet 7, without Mono, Xamarin and any dependency on NetFramework (Windows) or Mono (Linux, MacOS). All CLI projects can be opened in Visual Studio Code and debugged on any OS (macOS, Linux, Windows) without the need to use Xamarin, Visual Studio or Visual Studio for Mac. A new UI is in the works that will finally remove the dependency on Mono and Xamarin, but we don't have a release date to announce yet. The MacOS CLI is new (previously there was only the UI, or the UI with "-cli"), and it's also native for arm64. Overall, there has been a significant effort to clean up and modernise the code, and to prepare our build/deploy scripts for the new UI as well. We understand that there are still tickets or posts that we haven't responded to yet, but we preferred to complete this step first. Main changelog: [new] WireGuard is now the default communication protocol [new] All CLI editions can be compiled and debugged with VSCode and .NET7 [new] [macOS] CLI-only edition, built with .NET7, without Xamarin [new] New commandline only option "elevated.method" [change] OpenVPN 2.6.9 [change] [linux] CLI edition, built with .NET7, without Mono [change] [linux] .deb and .rpm, removed Mono dependency [change] [linux] .deb package tries to initialize elevated service at install/uninstall, .rpm package still missing this feature. [change] [windows] CLI edition, built with .NET7 [change] [all] Better management of SIGTERM signal [change] [all] Don't check if app dir is writable for portable-mode, now managed by presence of "portable.txt". [bugfix] [linux] terminal issue with sudo elevation [deprecation] [all] -cli mode for UI. Use CLI edition directly, now available in all supported platform. [deprecation] [windows] Vista builds [deprecation] [windows] Windows Firewall Network Lock mode [deprecation] [linux] x86 builds [deprecation] [linux] Portable Mono builds

Hello! Excellent in our infrastructure even on agnostic networks. We would not modify anything else, especially because you are in a network that's shaping VPN traffic. Obfuscation in place of true encryption is less CPU intensive but the solution you adopted is solid. According to a recent paper by Usenix titled OpenVPN is Open to VPN Fingerprinting, OpenVPN over SSH has a filter rate of 0.32, making it the third best technique to defeat filters against OpenVPN. Kind regards

@cyberslav Hello! Eddie needs pkexec but it is not pre-installed. Please install it and the problem should get solved. Usually it is included in the policykit-1 package: sudo apt install policykit-1 but it could now have its own package in 23.10: https://ubuntu.pkgs.org/23.10/ubuntu-main-amd64/pkexec_123-1_amd64.deb.html After the installation you should see (among other new files) /usr/bin/pkexec and Eddie will find it as the directory is in the command path. Kind regards

Hello! If you prefer that Eddie picks always a server in the USA please open the "Countries" window, select the United States and click the green check-mark on the right. USA servers will be added to the countries' white list. Eddie chooses, at each session, the highest rated server among those included in a white list. It is a tribute to Douglas Adams: https://en.wikipedia.org/wiki/List_of_The_Hitchhiker's_Guide_to_the_Galaxy_characters#Eddie That's great. Welcome aboard! Kind regards

@visy Hello! Apparently either UDP packets or OpenVPN are blocked. Please check any packet filtering tool both on your system and router. On the router check any "Quality of Service" or "traffic management" tool as well. Also, test a connection through WireGuard. It works only in UDP so if it can connect successfully then you know that the block is OpenVPN or port specific, and not against UDP in general. To have Eddie switch to WireGuard: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard, for example WireGuard port 51820. The line will be highlighted. click "Save" and re-start a connection to apply the change please make sure to test a few servers in different locations around your node Kind regards

Hello! You deleted the report... please check and re-upload, or just tell us whether the problem was solved. Kind regards

Hello! Please avoid the 32 bit version. You need the 64 bit version (NOT the legacy version), direct link: https://eddie.website/repository/AirVPN-Suite/1.3.0/AirVPN-Suite-aarch64-1.3.0.tar.gz Kind regards

Hello! We're very glad to inform you that 6 new 1 Gbit/s (full duplex) servers located in Miami, Florida (USA), are available: Aladfar, Ascella, Chertan, Elkurud, Giausar, Meleph. The servers support OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. 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. 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/Aladfar https://airvpn.org/servers/Ascella https://airvpn.org/servers/Chertan https://airvpn.org/servers/Elkurud https://airvpn.org/servers/Giausar https://airvpn.org/servers/Meleph Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Staff

@AuContraire Hello! We will start an investigation as soon as possible. Currently our testing machines include Pi 3 B, Pi 3 B+ and Pi 4, and not Pi 5. We will update this thread when we have relevant information. Can you tell us in the meantime whether the AirVPN Suite fails to start? https://airvpn.org/linux/suite/ Kind regards

Hello! Can you tell us the Operating System running in the Pi 5? We suspect an incompatibility with a specific Raspberry Pi OS version. Kind regards

Hello! Sorry, but your message contains FUD and fantasy. The Swiss Federal law about the Surveillance of the Post and Telecommunications enforces 6 months of metadata and e-mail headers retention to ISPs with more than 100 M CHF of revenue per year for at least two years in a row or receiving more than 100 requests of information in a single year. All the exemptions and obligations here. Furthermore, your alleged retention obligation of encrypted transiting data in unencrypted form not only is not required, but it is also physically impossible when the ISPs don't have the decryption keys, i.e. always, for any practical purpose (impossible every time end-to-end encryption is used). In this case the law does not try to enforce something impossible, at least. Kind regards

@KingBletsoe Hello! The Phantom virtual network adapter might be the culprit. Please try to force Eddie not to use other adapters and check whether the problem gets solved: https://airvpn.org/forums/topic/56643-stuck-in-a-broken-route-never-connects/?tab=comments#comment-225323 If the problem persists you might suffer a block against UDP or OpenVPN. Please try to switch to WireGuard: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard, for example WireGuard port 51820. The line will be highlighted. click "Save" and re-start a connection to apply the change please make sure to test a few servers in different locations around your node WireGuard works in UDP too, so if you have a block against UDP WireGuard will be blocked too. In this case please examine the packet filtering rules in your Windows system. We can claim that your ISP and/or your router are not the culprits because a similar connection works from your Linux device (assuming that both systems Internet connectivity is served by the same ISP and router). Kind regards

@discov Hello! Please reset the TCP/IP stack of the Operating System of the device with the issue. If this and/or a device reboot resolves the problem, please make sure that the network interface driver is up to date. If the problem persists after the mentioned operations but is resolved only after the router has been rebooted, please upgrade the router firmware, if possible. Kind regards

WireSocks (not WireSock) also seems to fit the description. If so, it's software, not a VPN service. https://github.com/sensepost/wiresocks Kind regards

@pleasejustwork Hello! Please note that your *.airdns.org name is updated correctly, but it is updated only for one of your devices (the "Minecraft" one), as it's linked to that device only. Also note that TTL is 30 minutes, so on public DNS you may expect an update after 15 minutes on average (while update on the VPN DNS is immediate). Kind regards

@convincewithdaydream Hello! Anything relevant on the WireGuard log? Does the problem persist if you connect directly the host, without any virtualization? Kind regards

Hello! We inform you that the all the servers in Miami, Florida (US), will be withdrawn and replaced by six different 1 Gbit/s servers. The replacement is part of our ongoing process to rationalise infrastructure and upgrade hardware in the US. New servers announcement will follow in the very near future. The servers which will be replaced are: Acamar, Cursa, Gudja, Kang, Minelauva, Yildun. Kind regards and datalove AirVPN Staff

@amccombs Hello! UDP or OpenVPN might be blocked. Please make sure that no packet filtering tools, either on your system or router, block UDP. On the router please check any "Quality of Service" or traffic management tool. If you find nothing potentially interfering, please try a connection through WireGuard, just in case your ISP has some block against OpenVPN or specific ports. In order to have Eddie switch to WireGuard: from Eddie's main window please select "Preferences" > "Protocols" uncheck "Automatic" select any line with WireGuard, for example WireGuard port 51820. The line will be highlighted. click "Save" and re-start a connection to apply the change please make sure to test a few servers in different locations around your node Kind regards

Hello! Can you please tell us the FireOS version in your Fire device? Also, please be aware that the Eddie version in the Amazon store is outdated, as Amazon will not accept any newer version due to their policy forbidding apps that may invite to create an account on some web site but not accepting payments through Amazon payment system inside the app itself, a condition which we have no intentions to comply with (we will remove the app in the future from Amazon if terms don't change). So, if you're running an Eddie version that's older than 3.0, please download and install the latest Eddie Android edition APK from our web site and follow the instructions to side load it: https://airvpn.org/android/eddie/apk/tv/ If you are already running Eddie Android edition latest version (3.0 at the moment) further investigation is needed. When the app becomes unresponsive shut it down, re-run it and send us a report (it will include the logcat, so it should show also what happened when it froze). To send us a report, please open the "Log" view, tap the paper plane icon on the top and send us the link that the app will give you back. For privacy reasons you might like to open a ticket to send us the link to the full report. Also, keep in mind that when you run Eddie Android edition, you don't need configuration files to connect to AirVPN servers, as the app is fully integrated with AirVPN infrastructure. Kind regards

@NaDre Hello! Extradition process pertains to criminal offenses so it is inappropriate to mention it here. Quad9 was already challenged in a German court by Sony Germany following a preliminary injunction against Quad9 with the Regional Court in Hamburg to force Quad9 to stop resolving certain domain names. Quad9, according to their press release, received another request by Sony Italia et al. for other DNS poisoning before the previous appeal trial was concluded. In order not to open multiple legal fronts they momentarily complied. Now that Quad9 won clearly against Sony Germany who knows, they could decide to refuse Sony Italia et al. requirements as well and see whether, after the important victory in court which sets a great precedent in Germany, Sony Italia et al. can manage to obtain some preliminary injunction by some court or not. We're talking here of attempts which are matter for civil law, nobody ever called for any criminal offense. The above case pertains to requests by private actors to other private actors. A request by a Telecommunication Authority of a country to a private company in a foreign country should follow the proper jurisdictional channels through the courts and/or the Authority of the foreign country, if at all possible, and to date it is not known at least for what we know. The harmonization of the Single Market should aim at avoiding inconsistencies between Member States in policy matters which fall under the EU competence so some of your questions still remain unanswered. Kind regards

@183aTr78f9o Hello and thank you very much for your tests, patience and documented reports. All the problems you reported are being examined. Kind regards

@matmat Hello! WireGuard doesn't ever remove the public IP address of the peer. It must be done by a specific non-WireGuard task which does it for each session who had no handshake in any given 180 s timeframe. Therefore, this important WireGuard problem is greatly mitigated because the public IP addresses of the peers will not remain forever on the VPN servers (which is a grave privacy concern), but only for 3 minutes after a disconnection. "Reapplied" is just a glitch in the description, you can ignore it. Just use OpenVPN if this mitigation is not enough for your needs or threat model. Kind regards

@go558a83nk Hello! 😋 You are mentioning a case requiring a specific pre-routing and a specific forward rule on your pfSense machine which takes care of the additional forwarding strictly needed in this case. It's the pfSense machine with acts as a router, builds a NAT for any other device and also connects to the VPN server as its virtual upstream. pfSense then decides how the NAT operates, for example it pre-routes and forwards incoming packet reaching its VPN interface port 32400 to 192.168.1.4:32400 (port 32400 of the IP address of the physical interface of the machine running Plex). By the way nothing changes indeed: when you modified your AirVPN account port panel, note that you were obliged to modify the pfSense rule as well (you changed XUANGE_WG interface port 27183 to 32400), otherwise the rule would have never been fired, as nothing was sent to port 27183, and you would have had the same problem of the OP, obviously. The main difference with @robzeta setup which must be taken into account to offer correct suggestions is that robzeta's Plex receives packets on its sytstem's virtual tun interface (therefore "External port" in Plex settings terminology), while in your setup Plex receives packets on the physical network interface ("Internal port", in Plex terminology) thanks to the in-between NAT built by your router, but the principles are all the same. The original problem could be resolved therefore in two alternative ways: modify Plex settings to have it listen to port 32400 even as "external port" and leave VPN remote port "re-mapped" to client port 32400 modify the port panel to forward remote VPN port 39186 to VPN client port 39186 (same numbers, no "re-mapping") and leave Plex listen to "external port" 39186 robzeta resolved by applying the 2nd method. Kind regards

Hello! The other questions are answered in the ToS, specification page and Privacy Notice, therefore we invite you to read those documents, further clarifications may come from the community or from us if necessary: https://airvpn.org/tos The Terms of Service https://airvpn.org/privacy The privacy notice and terms, scroll down for additional safety measures according to best practices as well as GDPR prescriptions https://airvpn.org/specs Specs overview In AirVPN, the problem you mention is not related to USB specifically, because USB support is disabled on the kernel of our servers and any reboot to make the server re-start to run a different kernel in order to plug secretly USB devices will cause the server to be rejected by the infrastructure, but adversaries don't need to plug in USB peripherals. A more effective attack comes from outside the server and a defense against this attack is not possible on the server itself (simply because the adversary does not interfere with or touch the server), it must come from a pro-active action by the user. Please see here: https://airvpn.org/forums/topic/57163-pen-register-connection-logging-on-airvpn-server-janfeb-2020/ Kind regards