Staff

@arteryshelby Hello! We always report the location where the server is physically located. Cujam is in a datacenter in Berlin, unless M247 has a secret datacenter in Frankfurt and tells us for some obscure reason that it's in Berlin. We have not physically visited the datacenter in Berlin, but for us it makes no difference and we're not interested in publishing fake locations, unlike many of our competitors. Kind regards

@crasswonder Hello! Please test Eddie 2.18 beta and if the problem persists do not hesitate to open a ticket. To download Eddie latest beta version please see the first message of this thread: https://airvpn.org/forums/topic/45326-eddie-desktop-218beta-released/ Kind regards

@dedo299 Hello! It has been reported sporadically that OpenVPN3 library fails DHE re-keying when it is initiated on server side. The gathered data is unfortunately anecdotal but those few users who met the problem could resolve it by forcing Hummingbird to be the first to initiate a re-keying. Please add in your profile the following directive: reneg-sec 1200 and the problem should disappear. The above directive will tell Hummingbird/OpenVPN3-AirVPN to perform a re-keying every 1200 seconds (20 minutes). You can edit your profile with any text editor. Kind regards

@pfillionqc Hello! Yes, thank you for your correction, it was a mistake on our side. We are editing our message to not create confusion to thread future readers. We're glad to know that you managed to resolve the problem. Enjoy AirVPN! Kind regards

@pfillionqc Hello! Please make sure that UFW is disabled. It is an iptables frontend installed by default in Ubuntu. It creates custom chains and modifies rules, so you don't want it to interfere. Please allow packets to an additional bootstrap server too: -A OUTPUT -d 63.33.78.166 -j ACCEPT Also consider to drop Eddie 2.16.3 and use instead Eddie 2.18.7 beta or Hummingbird 1.0.2 Keep in mind that when you enable "Network Lock" feature your iptables rules will be overwritten by Eddie or Hummingbird and restored when the application exits, but that UFW can still cause troubles. @giganerd Those are filter table INPUT, OUTPUT and FORWARD chains' policies and it's correct that they are set to DROP. Any packet handled by any chain of the filter table that has not caused any jump in any rule is finally subjected to the default policy of the chain that's competent for that packet. Kind regards

@Boblebad Hello! Check your ticket for additional information, please. Also, remember that it's correct and expected that Eddie (or any other program of any kind operating on system settings) does not restore previous settings if it's not shut down gracefully. It just can't. Anyway, when you re-run Eddie, it will restore the proper settings at the first chance, i.e. the first time it is shut down gracefully. Obviously if it's never shut down gracefully it can never do that. Locking this thread which has been resuscitated after 4 years, improperly. Follow the ticket if problems persist. Kind regards

@ellert Hello! Did you talk about CPU load, memory usage or both? Would you like to publish a comparison and specify your Operating System name and exact version, as well as your hardware configuration? We do not observe what you report about CPU load (on Linux x86-64 and Linux ARM32/64) BUT another community member reported something similar, on a Celeron J1900 based box running Debian 10, so it's definitely something to keep an eye on. Kind regards

@iwih2gk Hello! It's important to know that Eddie 2.16.3 doesn't run properly in Debian 10. In Debian 10 please run Eddie 2.18 beta or Hummingbird. Remember in any case to disable UFW completely, if you need Network Lock. UFW is an iptables and iptables-legacy frontend which may interfere fatally. You may set iptables-legacy or nftables rules to accomplish your purpose. If you run nftables directly remember that: Eddie 2.18 beta does NOT support nftables Hummingbird fully supports nftables BUT will prefer by default iptables-legacy if available, so remember to force Network Lock based on nftables: --network-lock nftables Kind regards

Hello! @busolof Actually according to the log OpenVPN connected successfully and remained connected for several hours. Since Asus offered to replace the device, then something wrong that's specific to your own one might be the problem. Even the fact that you say that you can't upgrade to Asus Merlin is unusual. In AsusWRT routers, upgrading to Merlin is a matter of a few clicks, literally. https://blog.usro.net/how-to-install-asus-wrt-merlin-router-firmware/ We're confident that the router replacement will solve any issue. Or maybe the AX56U has some problem that makes its behavior inconsistent with the AC56U and AC68U (which is an AsusWRT router we own and which we based our tests on). @giganerd Reviewed the guide for AsusWRT and it is up to date. Kind regards

@jptor1234 The most common cause of the the error you experience is an obsolete curl version packaged with Eddie 2.13 or older versions. If that's the case, you're running an Eddie version that's years and years old, try to upgrade to Eddie 2.18.7 or at least 2.16.3 and the problem should be resolved as @gandalfthegrey noticed. TLS 1.2 is now the priority requirement and your curl version could be so old to be linked against an obsolete OpenSSL library not supporting TLS 1.2. See also https://stackoverflow.com/questions/46422590/curl-error-tlsv1-alert-protocol-version Upgrade OpenSSL too if necessary. Kind regards

Hello! We're unsure whether you can if the router reboots, but try anyway to take the system log (where we can also see the OpenVPN log), they are in "Advanced Settings" > "System log" > "General log" (copy all and paste for example). Just in case: also check whether a firmware update is available. If so, apply it and test again. Very old firmware versions did not support 4096 bit keys but Asus fixed it a long ago and Asus customer care specifically tested AirVPN profiles successfully. Another option you could consider if anything else fails is upgrading to Asus MerlinWRT. Kind regards

Hello! No, we don't throttle/cap anything. Kind regards

@giganerd @Nam5000 Hello! A clarification on our previous message about problems in Sony TVs with Android 6. OpenVPN for Android and Eddie Android edition run fine and the connection to the VPN is successful and working, traffic is properly tunneled. However, the problem with such TVs is that if you put them in standby while connected to a VPN server, the TV will reboot when it wakes up. See also: https://community.sony.co.uk/t5/android-tv/bug-android-6-0-1-reboots-after-enabling-vpn-apps/td-p/2284371 It is possible to sideload Eddie Android edition on Sony Android based TVs. Kind regards

@dbuero Hello, no, we don't throttle anything. In most cases throttling is self-inflicted, with or without awareness (strange but true). Second most common cause is traffic shaping by ISP. Kind regards

@ellert Hello! You can connect to your Raspberry via SSH or VNC and follow the instructions for Raspberry here: https://airvpn.org/hummingbird/readme/ Make sure to pick the correct binary according to your system distribution architecture (32 or 64 bit). If you need Hummingbird to start at Raspberry's bootstrap, you can enter the command to run it in /etc/rc.local for example. When Hummingbird is not running in a terminal emulator, if necessary you can stop it cleanly via kill, for example: sudo kill `pidof hummingbird` Kind regards

Yes, sorry for the incomplete answer. You need to edit it with root privileges (example "sudo nano /etc/resolv.conf") and restore your favorite nameservers. Kind regards

@Kenwell That's great to know! We reproduced the issue with a Sony Bravia in summer 2019 and we had a document from Sony claiming that it was not considered a bug and no fix was needed because if you don't use a VPN the TV does not reboot (!) After that we did not have any other Sony TV to test and we did not buy any. Thanks for the information! Kind regards

Hello! No doubts, but Hummingbird can't run properly then. However, as we wrote, we will soon propose a daemon which will run even in SysV-init based systems. Kind regards

Not even one unfortunately... but we have a plethora of ARM processors. Another very weird occurrence in your case is that you have LESS throughput with CHACHA20 than with AES, which is unexpected indeed on a non-AES-NI supporting system. Actually we observe the opposite on ARM based devices (better throughput and longer battery life). Let's see whether somebody else can report from some similar system. EDIT: how do you use OpenVPN 3 library in your system? We see a huge boost when compared to Hummingbird, it could be a good starting point to check various things. Kind regards

Hello! You need to resolve this paramount problem first: System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down Debian 10 is based on systemd, failure to start systemd will cause all sorts of problem. The current version of Hummingbird relies on systemd, so if it can't start Hummingbird will not operate correctly, we're sorry. Why is your Debian 10 based distribution unable to boot through systemd? As far as we know Debian 10 is not really usable without systemd. EDIT: Hummingbird "evolution" into a daemon will support SysV-Init based systems. Kind regards

@SurprisedItWorks It's a recognized bug affecting especially Sony TVs. Sony is not fixing it. You would experience the same with Eddie Android edition or any other VPN application, unfortunately. @Xianders APK for Android TV should be side loaded, as the Play Store will not make it available to Android TV because Eddie opens airvpn.org web site in some menu , while Amazon Appstore makes it available for Android TV (different evaluations). Here you can find the link to download the apk: https://airvpn.org/android Kind regards

@muelli Thanks. We failed to reproduce it, but it must be said that we don't have a Celeron at all. Does anybody else observe a 100% CPU load, or anyway high CPU load? If so, at what throughput? Kind regards

@aSystemOverload Quite the contrary in your specific case: Network Lock works just fine. When an Eddie's connection attempt fails, Network Lock remains active. It will be disabled only if you specifically order to de-activate it, or if you close Eddie. Kind regards

@muelli Hello! We have not observed the behavior on our testing machines and it has never been reported before, so it needs to be investigated from scratch. What is your exact Linux distribution? What is the CPU usage if you use AES-CBC and AES-GCM? Kind regards

@bm9vbmUK Hello! Please check here: https://dockerquestions.com/2019/07/07/docker-debian-buster-nftables/ Reading on the article, it seems expected that both iptables-legacy and nftables can not be used in Docker. In such a case, you need to consider manually a "network lock" solution. Classic iptables should have no problems but it is not available in your images as far as we know. By the way, if it is you should install it, make sure to purge nftables, and force Hummingbird to use iptables with "--network-lock iptables" Kind regards