Staff

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 supports 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 server accepts 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

Hello! That's not true in general. It's true only if Plex listens to the "public" (as it is called in Plex settings) port 32400 too. With the previous configuration the VPN client received packets on tun interface (the VPN virtual network adapter) port 32400, while Plex listened to port 39196. Now the user has resolved the problem through the provided suggestion, i.e. the remote port is forwarded to the tun interface port which is the public listening port on Plex, NOT 32400. To be clear: now the Plex server listens to public port 2***7. The port panel of the user is configured to forward remote port 2***7 to client port 2***7 (same port number). Everything works as expected. If the VPN server remote port were forwarded to VPN client port 32400, the same problem would occur, as the packets would arrive on tun interface port 32400. Plex would not listen to tun interface port 32400. It would therefore see nothing on VPN interface port 2***7, the port it listens to ("public port"). Please make sure you understand that physical interface port 32400 is not VPN interface port 32400 and that Plex listens always to port 32400 of the physical interface while you are free to configure any public port you wish. It's important to understand all of this. We have reviewed some old tickets related to Plex problems caused by exactly this misunderstanding. As an additional didactic aid, please visualise the flow of incoming packets when the listening programs are running on the same system that's connected to the VPN: when such packets pass through the system's physical interface, the underlying header and payload are still encrypted, so the port set of the physical interface never plays a role in the incoming virtual private network packets. Here above you find the explanation, it might come handy to you and any other Plex user. Kind regards

Hello! You may tell Eddie to activate Network Lock at startup in the "Preferences" > "General" window to have your rules overwritten. The total block you enforced will prevent Eddie (and any other program) to communicate to and from localhost. This may break several programs, you should add allow rules to and from 127.0.0.1 at least. Eddie frontend and backend talks to each other via TCP on 127.0.0.1. Please note that the activation of Network Lock requires that Eddie can talk to the backend process (the only one running with root privileges) so the total block you enforced can not be circumvented by Eddie, not even if Network Lock must be enforced as soon as the program is launched. Kind regards

Hello! Yes, as we wrote (and you couldn't know, but now you know) @robzeta had forwarded, on the AirVPN port panel, remote port 39196 to local port 32400. Therefore Plex, which was configured to listen to public port 39196, could never receive packets. Also (and you couldn't know it as well) the forwarding was active only for UDP (note that the port tester performs a test only in TCP and correctly returned error 111 as expected). Now, @robzeta has deleted port 39196 altogether, so let's wait for the new tests. Another clarification, this time for us: in the Plex documentation here https://support.plex.tv/articles/200289506-remote-access/ we read: Therefore we guess that the Media Server refuses to listen if you don't have an account or you did not sign this account in to some other service managed by Plex Inc.? Can you confirm? Kind regards

@DrunkenDesperado Hello! Please test WireGuard and verify whether you have any improvement or not. In order to switch to WireGuard: from Eddie's main window please select Preferences > Protocols uncheck Automatic select a line with WireGuard (example WireGuard, port 58120...). The line will be highlighted click Save and test connections to various servers in various locations Kind regards

Hello! Nearly impossible to say without more information. To begin with, please mention your Operating System(s) name and version, the program you run to connect to the VPN servers, the settings of this program and the traffic management rules of your ISP (if any and if you know them; they should be mentioned in the contract or in the public information under "Quality of service" or "bandwidth fair use" or "traffic management" sections). Kind regards

Hello! Here a serious complication might have entered into play. UFW does not support nftables, while all modern distributions are based on nftables for the packet filtering system. Eddie does support nftables and correctly uses it. UFW must rely on translations back and forth performed, for example, by iptables-nft. However the translation tools do what they can, but if you start mixing iptables with nftables syntax rules, by experience we know that "bad things will happen". If you have an nftables based distribution and you want to use Eddie's Network Lock (or the AirVPN Suite) you have two options: 1. avoid UFW, which after all is a frontend of a frontend of a frontend, by disabling it, and operate on the firewall rules directly with nft. To disable UFW the following command should be sufficient and permanent: sudo ufw disable 2. Alternatively, force Eddie to use the iptables-legacy system. Open the "Preferences" > "Network Lock" window and select "iptables-legacy" on the "Mode" combo box. By forcing consistency of rules' syntax by all the programs operating on firewall rules the translator tools should work properly. However, if your system is still entirely based on iptables (no nftables at all) then the above can not be the cause of the problem and it's necessary to look elsewhere to find the problem roots. Kind regards

@robzeta Hello! Port 39196 reserved to your account is UDP only, so failure on TCP is expected. If Plex needs TCP as well please act accordingly on your account port panel. Furthermore, port 39196 is forwarded to your VPN IP address port 32400, so Plex will never receive any packet on port 39196. This explains also the connection refused error on port 39196 (a test which our port tester runs anyway): your system receives packets on port 32400 and correctly resets the connection. Adjust this setting too. Kind regards