Staff

@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

Hello! The maintenance work in UK is over. Do you notice any improvement? We see a good performance from Italy and a few countries in Europe. After the maintenance/upgrade a UK server has also reached the Top 10 (!) user speed with 631 Mbit/ to a single client. Kind regards

Hello! Would you disclose those reasons (in private, if necessary)? We have put Hetzner in a black list (to avoid to rent or house servers of any kind in their infrastructure) since 2014 or so, but the reasons for the black listing have been lost in the notes unfortunately after this last decade. Kind regards

Hello! AirVPN DDNS management is not strictly related to your system as the domain names are managed by AirVPN and through your AirVPN account port panel. Please see here: https://airvpn.org/faq/ddns/ DDNS comes very handy together with inbound remote port forwarding, please see here: https://airvpn.org/faq/port_forwarding/ OPNSense configuration should be based on OPNSense manuals, but for the concepts related to AirVPN and a program listening to some specific port on the VPN interface you may also consult this very good pfSense guide: https://nguvu.org/pfsense/pfsense-port-forward/ Kind regards

Ok, you had written a completely different story. In this case, check the best answer in this thread, it tells you all. Kind regards

Hello! Assuming that you are right in reporting that Hetzner doesn't want torrent at all, then we say that it should be avoided because forbidding torrents hinders distribution of content, in particular free and open source software, blocks applications that may be useful or vital for a user of a dedicated or virtual server, and in general affirms the dangerous principle according to which it is reasonable to offer a subset of Internet application layer protocols by discriminating a specific protocol at a specific higher layer on a datacenter. It may also be matter of debate for potential breach of the regulatory framework set by EU 2018/1972 Directive etc. No discrimination or white listing at transport layer and application layer should be enforced. Can you point us and the readers to the policy where it is stated that BitTorrent is not allowed in Hetzner infrastructure? Kind regards

@georgek3r Hello! Hetzner can not prove which protocol/application you run in the VPN tunnel and what type of traffic you tunnel, as we do not have servers in Hetzner infrastructure, but it can see that you run qBitorrent if personnel accesses your server from KVM/IPMI (and potentially this is possible). If your server is virtual, they can see it even more easily. If (and only if) what you claim is true (we have no idea), Hetzner should be avoided because p2p protocols, including BitTorrent, are very important to the Internet today and used by a wide variety of services. Connecting to a VPN server in a country different from the one you live in is a golden rule that can make life harder to snoopers and wiretappers as the servers are in different networks and different jurisdictions. Assuming no traffic leaks outside the VPN tunnel (important!), any activity observed by an external observer will be seen as coming from the VPN server exit-IP address and the correlation to your Hetzner IP address is impossible unless the observer is a very powerful adversary (NSA for example, or an entity monitoring the whole "your home country" infrastructure in real time and globally - another reason to pick a server outside your home country) or your system is compromised (remember how any VM can be easily observed by dc personnel). Kind regards

@OpenSourcerer Hello! Our source is M247 only. The problem affected intra-Asia connectivity and Europe to Asia connectivity at least and was visible on the other provider in Singapore (Leaseweb SG) too. From Europe you should have been able to see for example troubles on NTT when you reached Japan and Singapore. The problem was generally limited to some notable congestion on peak times but some packet loss was visible frequently. As of yesterday night (CEST) some problems seem solved and the connectivity has improved remarkably. The last ETR reports Sep-23 but that's a worst case, it looks like some repairs were completed if you look at performance (we may ask for a new report in a few days if problems re-appear after that date). Kind regards

@Fred H Hello! No domain names exist for bootstrap server IP addresses but we see that they are not blocked, in spite of what you wrote Eddie can talk with them fine. From the report the problem is different, apparently it's the VPN connection (by WireGuard in your case) that's blocked, probably you just need to require no restriction against UDP toward one of the WireGuard ports of our servers (1637, 51820). Kind regards

Hello! Thanks, problem understood. A bug fix is coming in the very near future. Kind regards

Hello! Eddie also sends out data to bootstrap servers over HTTP, toward port 80. The data is encrypted. Additional checks you might like to perform are: make sure that the system does not block HTTP connections without a domain name resolution (Eddie uses direct IP addresses, and this behavior can be blocked by specific security systems) make sure that the system does not block encrypted data inside an HTTP flow to port 80 Also feel free to send us a system report generated by Eddie if you want that we examine what apparently goes wrong. Kind regards

@ltwally Hello! The bluetit.lock file shows that Bluetit is right in claiming "It seems Bluetit did not exit gracefully or has been killed." etc. While Bluetit is not running delete that file and set the proper DNS for your system to restore a clean status. If you killed Bluetit without grace this behavior is fine. But if your did not, then the reasons of the previous crash should be investigated. As soon as the problem re-surfaces please send us the complete Bluetit log from journalctl. Kind regards

@Exactlie Hello! According to the log UDP seems blocked: Please check the packet filtering tools running on the system and the router and make sure that they do not block UDP. If you find nothing blocking, probably you will be forced to rely on TCP only (possible UDP / OpenVPN block by your ISP). You can change connection mode in Eddie's "Preferences" > "Protocols" window. In this last case it's worth testing WireGuard. Although it works on UDP only, if the block by the ISP is against OpenVPN and not against UDP you could connect successfully. Again, you can switch to WireGuard on "Preferences" > "Protocols" window. Kind regards

Hello! Thank you, fixed. Kind regards

@zsam288 Hello! We confirm the bug at the first run, and we confirm that the tile button does not get updated the first time the app is launched when a connection is established from the app menus (the button remains gray and tells "not connected", as you correctly noticed). Under investigation for a quick fix in the next release. @Fezenari We can't reproduce the crash on any of our testing machines, can you please send us a report to let us investigate? After the app has crashed, re-run it (please do not reboot the device) and tap the paper plane icon on the "Log" view, then send us the link that Eddie will give you back. Eddie will send out the logcat too which should contain a thorough report of the previous crash. Kind regards

Hello! For bootstrap servers (special servers used to download encrypted info about VPN servers and your account) and for VPN connections toward AirVPN servers Eddie Desktop edition (Linux, Mac, Windows) never relies on domain names. When you send a system report to our infrastructure for diagnostic and technical support, Eddie needs to resolve eddie.website domain name. Kind regards

@ltwally Thanks. Can you please send us the content of /etc/airvpn as well? sudo ls -l /etc/airvpn 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.1.0 is now available, featuring a complete update of all libraries, enhanced TV support, a new quick setting panel tile, revamped VPN profile generation, connection control buttons on notification, specific Android 14 support, GPS spoofing (default: off) and much more. Special notes on the new GPS spoofing feature: if enabled, the location of the device will be set to a fake GPS position upon a successful VPN connection. When connecting to an AirVPN server, the location will be set to the country where the VPN server is located, through predefined coordinates. If the device connects to a non-AirVPN server, random country coordinates will be selected. To test and use this new feature, please set Eddie as the "mock location app" for your device in the developer settings page (only one app at a time can be the mock provider). Once enabled, you can also set the GPS spoofing refresh interval between 10, 5, 3, 1, 0.5 and 0.25 seconds (default: 1 second). The options are available in the Settings > System view. 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.1.0 new features list Eddie Android 3.1.0 (VC 32) Added support to Android 14 Updated to OpenSSL 3.3.1 Updated to the latest OpenVPN3-AirVPN library fork Updated to WireGuard 2e0774f Updated to the latest AirVPN Suite specifications and functions Added quick setting panel tile for quick connection and disconnection Optional GPS Spoofing (requires system's developer options to be enabled) Improved VPN profiles generation Mass import of OpenVPN and/or WireGuard profiles Auto AirVPN user login at startup Server score sort in AirVPN Server tab Show and log connection statistics at disconnection Added permission checking at startup according to user's settings Added optional "quick tap" connection to AirVPN server tab WireGuard handshaking timeout manager can be enabled or disabled by user Added connection control buttons to notification Improved Android TV D-Pad navigation, notably left and right arrow for opening and closing the menu drawer Added Manifest's [AirVPN document served by bootstrap servers to provide clients with several pieces of information] preset connection modes. Select them in the Preferences > AirVPN view. Revised connection dialog management Several bug fixes (special thanks to community testers) Download link https://eddie.website/repository/Android/3.1.0-VC32/EddieAndroid-3.1.0-VC32.apk SHA-256 checksum d33c99e9eb300e40bf21c44bd654d1f79671fa8e7660aefe80f72f0ecd2d38a4 *EddieAndroid-3.1.0-VC32.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

@ltwally Thanks. Can you please send us the content of /etc/airvpn as well? sudo ls -l /etc/airvpn Kind regards

Hello! WireGuard is in 10.128.0.0/10 (gateway 10.128.0.1) and fd7d:76ee:e68f:a993::/64 (gateway fd7d:76ee:e68f:a993::1) Kind regards

Hello! It was implemented a long ago. On Linux: Eddie Linux edition supports traffic splitting on a destination basis the AirVPN Suite 2.0 for Linux (currently in beta testing) supports per-app reverse traffic splitting through Bluetit and Cuckoo. We have managed to avoid Mullvad's long standing problem of inverse DNS leaks but the system is not fully compatible with systems purely based on Wayland at the moment (anyway you can use it just fine with X.Org or without desktop) Kind regards

Hello! We have been informed of the ETR for serious problems in intra-Asia and Europe to Asia connectivity to Japan and Singapore, ranging from 2024-09-04 to 2024-09-23 (!). Kind regards

IMPORTANT UPDATE: https://airvpn.org/forums/topic/62706-multiple-fiber-cuts-in-sg-and-jp/