Staff

Hello! Please start from here: https://airvpn.org/faq/p2p/ If you need some additional information on remote inbound port forwarding, read this as well please: https://airvpn.org/faq/port_forwarding/ The service is not Eddie specific, but it's a server side feature not affected by the software a client runs to connect to VPN servers, so we're moving this thread to "Troubleshooting and Problems" forum. Kind regards

In a specific older qBittorrent version (we can't find which exact one at the moment, we're sorry) it was necessary to set "Tools" > "Preferences" > "Advanced" > "Optional IP address to bind to" combo box into "All IPv4 addresses". If it was set to "All IP addresses" the app responded only to IPv6 on FreeBSD systems (we guess on macOS too, therefore). This problem has been fixed at least six months ago, as far as we can see. Kind regards

Hello! Is the Windows system successfully connecting with WireGuard through the same ISP and the same upstream router? If so, the problem should be Unifi specific. Could you please send us the WireGuard log while the problem is ongoing? Can you also make sure that the WireGuard interface is up and running on the USG (please check the interface status by connecting via SSH to the device and entering either wg show or ip addr show command). Also check whether you can ping the VPN gateway directly from the Unifi device during your SSH session on the Unifi (ping 10.128.0.1) while the WireGuard connection is allegedly up. Kind regards

Hello! Please try MTU set to 1280 bytes, if you haven't already done so. Kind regards

Hello! We confirm the problem and we could determine that both the domain name authoritative DNS and the web site block the Taiwan server. Packets get out regularly from the server and from Taiwan but they are black holed by the final destination datacenters. Furthermore the authoritative DNS does not answer to our DNS server in Taiwan (this is a lesser problem as you could resolve the name through some other public DNS or the hosts file). We don't know the reasons of this behavior. If you query Democracy Now and you receive a reply please let us know. In the meantime we can "micro-route" Democracy Now web site from Sulafat, we will examine how to do it soon. Yes, this is in the official ISO-3166 that Eddie uses to find areas names assigned by the United Nations. According to a previous administrative division, Taiwan is the biggest province of the Republic of China (ROC), not to be confused with People's Republic of China (PRC, mainland China). By using Taiwan as the country's name, "Province of China" is also a definition pushed by PRC at all levels (from UN to NGOs) to shape two ideas: that PRC must "re-unify" with Taiwan and that when you say "China" you don't talk about the Republic of China, but about the PRC (even PRC detractors fall prey of this propaganda as we can see from this thread). In this sense ISO-3166-2:TW entry could be seen as a concession to PRC narrative and the PRC can "play" over the ambiguity of the definition. In the next version we may either stay with this one, according to the United Nations status (but see here for some arguments against this), or censor the ISO document itself. A UN spokesperson’s statement in May 2024, reiterating that Taiwan is a province of China (referring to PRC and not ROC according to directly or indirectly PRC controlled media), guided by the General Assembly resolution of 1971 (Resolution 2758), is important to see how much energy PRC spends to affirm the notion that there is only one China and this only China is PRC and not ROC. On the other hand, we have been fighting and circumventing mainland China (PRC) censorship for 14 years, we recognize China (PRC) as a country enemy of the Internet, controlled by a regime hostile to various human rights, and in reality resolution 2758 interpretation may have been distorted by PRC.. Therefore ISO-3166-2:TW unilateral modification to delete "Province of China" is not unreasonable for us. The matter will be discussed. However, to insinuate that the normal software usage of an ISO document to translate or find a country/area name means that AirVPN endorses PRC (or PRC alleged wet dream to invade Taiwan) or that AirVPN fails its mission after all the sacrifices brought on to circumvent censorship in mainland China is offensive to say the least, or not in good faith in the worst case. The very fact that we list the server in Taiwan with Taiwan as a country tells a lot, as today Taiwan is recognized as a country only by 12 countries in the world. Kind regards

Hello! You can download the binaries by clicking the links in the first message of this thread. Kind regards

Hello! The disconnection problem is not a matter we will investigate here (please open a ticket if you want to have the support team look into it or wait for community feedback here). Apparently Bluetit failed to restore the previous DNS settings in your system. The potential problem can be caused by the following bug: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1872015 Now, to restore DNS system settings make sure that Bluetit is not running and set the proper DNS (we recommend Quad9, 9.9.9.9, 149.112.112.112 and 2620:fe::fe) . Then, verify whether the system is affected by the bug: ls -l /etc/resolv.conf If you see that the symlink is relative, such as: lrwxrwxrwx 1 root root [...] /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf then Bluetit can be unable to restore properly DNS (a workaround will be implemented to let Bluetit run properly even in bugged systems). The relative path for a symlink may perhaps make sense in very specific circumstances but in this case it is correctly considered as a bug. If you find that your setup is bugged, fix it simply by entering the commands shown in the quick fix available in the above linked bug report (make sure that Bluetit is NOT running). Verify the content of the directory /etc/airvpn and delete any lock and/or backup file you find there (do not delete other files as they are essential for Bluetit). Start Bluetit, connect to some VPN server, disconnect, shut down Bluetit and verify that the DNS setting have been restored properly. Please feel free to keep us posted. Kind regards

Hello! It's ISO 3166 used by Eddie. Kind regards

Hello! Thank you for your tests again. The log shows that IPv6 push is fine and accepted, it shouldn't be a general Eddie 3.2.0 beta 1 issue. If possible, please test Eddie 3.1.0 or 3.0 (stable versions) and tell us whether you see the same problem. Kind regards

Remarkably slower and not more secure but definitely more capable to bypass blocks, that's the key (for the readers, if your ISP doesn't block WireGuard and OpenVPN do not use an additional SSH tunnel). Kind regards

@fruchtenstein Hello! It is not supported by Eddie Android edition, we're sorry. Please see here for manual setup: https://airvpn.org/forums/topic/13486-ssh-tunneled-vpn-on-stock-android/ It is possible that this feature will be implemented in some future Eddie Android edition version, but it is not planned at this very moment. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s (full duplex) server located in Taipei (Taiwan), is available: Sulafat. The server supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. The AirVPN client will show automatically the new server; 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. This is our first server in Taiwan; the tests we have performed during the last week have been encouraging but not totally perfect for our quality standards. Your feedback is welcome and it will be crucial to determine whether this server's datacenter can meet your expectations and requirements. You can check the status in our real time servers monitor: https://airvpn.org/servers/Sulafat/ Kind regards & datalove AirVPN Staff

In that case we can, of course. Kind regards

Hello! Eddie Android edition is a fully integrated with AirVPN, free and open source WireGuard and OpenVPN GUI client. It is based on official WireGuard library and latest OpenVPN3-AirVPN library (free and open source software library by AirVPN), allowing comfortable connections to both OpenVPN and WireGuard servers. All Android versions from 5.1 to 14 are supported. We're very glad to inform you that Eddie Android edition 3.2.0 beta is now available. The main goal is fixing all the known bugs affecting Eddie 3.1.0 stable release which went unnoticed or were not properly fixed through the previous beta testing and releasing a new stable version in a short time. Please check Eddie 3.1.0 new features if you are upgrading from a version older than 3.1.0. Please report at your convenience any bug and problem in this thread. If possible generate a report from the app: by tapping the paper plane icon on the Log view bar rightmost side you will generate a full system report which will include both log and logcat and have it sent to our servers. Then you just need to send us the link the app shows you (open a ticket if you prefer to do it in private). Please remember that, starting from Android TV 10, Always On VPN feature has been stripped off in order to prevent users from connecting to a VPN during an Android TV based system bootstrap. Therefore Eddie start & connection at bootstrap, as well as system built in leaks prevention, are not possible on Android TV 10 and higher versions. For leaks prevention you can rely on Eddie's "VPN Lock" feature. Android TV 9 and older versions can still start Eddie during the bootstrap and have it connected when you activate Always on VPN and configure Eddie accordingly. Eddie 3.2.0 beta changes Eddie Android 3.2.0 beta 2 (VC 33) updated to OpenVPN3 3.11 AirVPN (20240912) updated to OpenSSL 3.3.2 fixed pause/resume button status according to network status change (OpenVPN) fixed a bug which caused the app to rely on VPN servers domain names for AirVPN country connections at device bootstrap fixed a bug which caused the app to crash on some systems if no network was available at device bootstrap fixed a bug which caused a paused OpenVPN connection to resume after a network change fixed AirVPN manifest management, particularly during concurrent network access and VPN startup improved Quick Setting Tile interaction improved VPN connection at startup (device bootstrap) by checking and properly managing critical system and network conditions Eddie Android 3.2.0 beta 1 (VC 33) fixed a pre-packaged manifest issue which caused the app to crash when a profile was imported and the proper manifest could not be downloaded fixed a bug which caused the quick tile button to become unresponsive in some systems after the app was swiped out fixed a bug which caused the app's quick connection button to become unresponsive after or during an OpenVPN session fixed a bug which caused the quick tile button status to get misaligned with the actual app status fixed a bug which caused the app to show a status different from the actual device and/or VPN status fixed a bug which caused the app to ignore the white list at the first connection through the quick tile button and in other circumstances fixed a bug which caused the app not to update the white list after a user already defined it and later changed it added profile deletion multiple selection added an optional real time log view update and refresh Download link https://eddie.website/repository/Android/3.2.0-Beta2/EddieAndroid-3.2.0-Beta2.apk SHA-256 checksum 6e8e0f2ee287467a67c1791de4a3ad779d087ae3d7a865b1deb22051d4639d97 *EddieAndroid-3.2.0-Beta2.apk How to sideload Eddie Android edition on Android TV and FireOS devices https://airvpn.org/android/eddie/apk/tv Kind regards & datalove AirVPN Staff

Hello! Leaseweb SG's Antares is not decommissioned, as we have contractual agreements until August 2025 for it, but due to Leaseweb behavior it is down a lot of time, so we will abandon Leaseweb SG definitively after we have fulfilled our contractual commitment. Kind regards

Hello! Yes, we do have expansion plans in Asia. Kind regards

Hello! This is most puzzling, we'll take this into account with M247. Please perform mtr tests and let us know whether you have the same path to Air and Mullvad servers, if you have time and will. Kind regards

Hello! So it's a problem you experience only with UK servers, and only with upload, right? Does it happen both on London and Manchester? It is not reproducible from our sides so at the moment we have to consider that everything looks fine. Any additional hint from other users is welcome. At least the original problem "slow download" is resolved for everyone. Kind regards

Hello! We do not have any M247 server in the Netherlands. Kind regards

Hello! The CG can generate configuration files for OpenVPN 2.4, 2.5, 2.6, 2.6 no-dco and 3. 2.4 does not support several 2.5 directives, while 2.5 and 2.6 deprecate or do not support anymore some 2.4 directives. 2.6 can be incompatible with 2.6 no-dco. Please make sure to generate a configuration file for the proper OpenVPN version you run. Turn on the "Advanced" switch to see the combo box that lets you select the OpenVPN version of the configuration file ("OpenVPN profile" combo box, default value 2.5). Kind regards

Hello! You might have a cap in UDP upload, very typical of many ISPs throughout the whole European Union, 24h/24 or during peak hours, or even unconditional upload cap for any protocol not white listed (typically they list only HTTP, HTTPS, sometimes FTP). The price of traffic routed outside the ISP local network is very different from the price of incoming traffic and activities like seeding, streaming etc. from a residential line are heavily curbed. If you connect to servers in another country with an identical connection mode, do you see higher upload speed? If you connect OpenVPN over TCP to UK servers do you see any upload improvement? We're glad to see anyway that your download speeds are now very good. Kind regards

Hello! You might have a cap in UDP upload, very typical of many ISPs throughout the whole European Union, 24h/24 or during peak hours, or even unconditional upload cap for any protocol not white listed (typically they list only HTTP, HTTPS, sometimes FTP). The price of traffic routed outside the ISP local network is very different from the price of incoming traffic and activities like seeding, streaming etc. from a residential line are heavily curbed. If you connect OpenVPN over TCP do you see any upload improvement? If you connect to servers in another country with an identical connection mode, do you see higher upload speed? Kind regards

@SiblingHacker Hello! Thank you very much for your tests! Bluetit implements reverse traffic splitting through a dedicated namespace and the utility cuckoo. According to your description, possible malfunctions come from: the fact that you do not run cuckoo utility to start applications inside the namespace aircuckoo. Use cuckoo to start any application whose traffic must be outside the VPN tunnel the fact that you specify a physical network interface that doesn't exist. What is ens1 in your system exactly? Bluetit must find a physical network interface to route the traffic outside the tunnel, it can't create in your hardware a new network card aircuckoo's virtual network interface is attached/paired to the physical network interface to obtain reverse traffic splitting (without any "reverse" DNS leak) any block to the physical network interface, which of course must route even the VPN traffic (although wrapped and encrypted): somewhere the virtual network must use a real, physical network Try to not specify the directive trafficsplitinterface, so you're sure that Bluetit will pick the physical network interface for the namespace aircuckoo for the mentioned attach, thus routing the traffic outside the VPN. Then make sure to start anything you need outside the VPN tunnel via cuckoo. Please feel free to report back. Kind regards

Hello! Bluetit works perfectly in many distributions, but this does not mean that it works perfectly in all the 800 (?) existing Linux distributions. Lubuntu is an Ubuntu derivative, so let's check first whether it is affected by this long standing bug which is still not fixed nowadays on Ubuntu: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1872015 To verify whether your Lubuntu system is bugged, just send us the output of ls -l /etc/resolv.conf while Bluetit is not running and the system is in pristine conditions. This bug is crucial in DNS management and could explain one (but not all) of the problems you reported. Of course it is not Bluetit developers' responsibility but a workaround can be found and implemented in the next Suite release as we don't think that the bug will be fixed in a reasonable time (it's still unassigned after so many years) so that no manual fix by the user will be needed. The manual fix is simple but it could be beyond the ability of some Ubuntu and Ubuntu derivative users. No, sorry, this is not acceptable when the lock file is existing. This belief was popular on Windows and now it has its supporters among some of systemd zealots, and look what the Linux world of many systemd based distributions have become today (also) as a result of contamination from Windows. An unclean exit that's not inside the range of recoverable causes foreseen by the software, especially when this software is a real daemon modifying routing table, firewall rules and DNS settings, requires investigation by the superuser, otherwise the superuser might be prevented forever to spot and detect an unclean exit, and that would be a huge problem indeed. Unfortunately this is not reproducible on our testing systems and we don't have other similar cases in the tickets. We don't have Lubuntu in testing systems, though, so it might be a distribution specific problem. We will investigate. In the meantime, if you haven't already done so, can you please remove the Suite 1.3.0 and test the 2.0.0 beta 1? Check whether any of the problems you report is solved or not, thanks in advance. To download the Suite 2.0.0 please see here: https://airvpn.org/forums/topic/56704-linux-airvpn-suite-200-beta-available/ Suite 2.0.0 beta 1 addresses various bugs, implements reverse traffic splitting and extends compatibility to a few more distributions, but remember that Lubuntu is not among our testing systems, so your reports will be valuable again. If any problem persists, we need to see again the complete Bluetit log after any problem occurred. Kind regards

@Exactlie Hello! OpenVPN is a system including protocol, client and server applications to establish point-to-point or site-to-site connections in routed or bridged mode. AirVPN infrastructure uses WireGuard and OpenVPN systems (which are quite different) to let customers enter the private network. That's expected. Eddie is an AirVPN software which relies either on OpenVPN binary or WireGuard code to let your system connect to the VPN. To avoid conflicts, if you already launched some OpenVPN program, then you must not run Eddie, and if you run Eddie then you must not run OpenVPN separately (it's Eddie that will launch, configure and manage OpenVPN, if you choose OpenVPN and not WireGuard). If you found nothing blocking UDP in your system or local network and the problem persists then it's possible that the block comes for example from your ISP. Kind regards