Staff

@65tiklak If you enforce Network Lock you should disable UFW. It is an iptables frontend which adds custom chains that may interfere. About the outcome of your tests, you therefore imply that the iptables rules mainly impair upload speed, and not download speed. It's a reasonable assumption, yes, because Eddie overwhelms the OUTPUT chain of the filter table. Use Hummingbird and make a new comparison please, for a potential confirmation of your assumption (with Network Lock on) as Hummingbird enforces only 19 rules on OUTPUT, instead of the 1000 rules enforced by Eddie. If you wish to reproduce Network Lock through UFW, just look at the rules enforced by Hummingbird, make sure to delete any UFW custom chain, and set your own. However using directly iptables (or nftables if you have a system supporting it) is probably a better solution, but it's up to your taste at the end of the day. Please keep us posted at your convenience after you have tested Hummingbird, even with CHACHA20-POLY1305. Kind regards

@65tiklak Hello and welcome aboard! Eddie's Network Lock enforces something like 1000 iptables rules and 1000 ip6tables rules, so in theory it might actually slow down a Raspberry. However the screenshots you report show no performance difference between Network Lock on and off, so your conclusions are incorrect according to your very own experimental data set. In the first example of yours, you even have slightly higher performance with Network Lock on. By the way it's not a big deal because the "problem" (if it was a problem) has been completely resolved by Hummingbird, which enforces only few rules, only the strictly necessary ones. It's like 30 rules, and there's no way that 30 iptables rules can measurably slow down Linux throughput in Raspberry. Your comparison with NordVPN is also not very relevant if you don't specify the cipher and the VPN protocol you have used. We allow, like NordVPN, weaker ciphers, but by default our servers propose the strongest available cipher, so you need to explicitly force the weaker cipher. Additionally we do not support insecure protocols like PPTP, which NordVPN still supports as far as we know. On top of that Hummingbird lets you connect with CHACHA20-POLY1305 cipher which will give a non AES-NI supporting system (like a Raspberry) a performance boost. Hummingbird is available both for Raspbian 32 and Ubuntu 19 for ARM 64 bit (and should be also compatible with any other ARM 64 bit Linux distribution). Hummingbird also calls OpenVPN3-AirVPN library, which is remarkably faster than OpenVPN 2 binary. Test it and let us know. Any Network Lock not enforced via firewall rules is garbage. Do not trust such kill switches because they will not prevent leaks when a process binds to the physical network interface and when the "switch killer" process halts unexpectedly. Please see here to download and install Hummingbird: https://airvpn.org/hummingbird/readme/ Kind regards

@arteryshelby Thank you, we will keep your suggestion in serious consideration. Kind regards

@BlueBanana Hello! Check the stats about used bandwidth on the total infrastructure day by day: As you can see, the used peak bandwidth has increased remarkably in the last days, up to 80200 Mbit/s. On the whole infrastructure, it is still slightly more than just 1/3 of the total available bandwidth (236900 Mbit/s). We will closely monitor, on top of that, used bandwidth country by country, of course. About the countries you mention, even the last peak usage does not exceed 60% of total available bandwidth in each of those countries. We are still well within the range of the quality of service ensured by the terms of service and actually most available bandwidth has not ever been used. That said, we will not hesitate to add servers when it is really necessary, of course. We are monitoring closely, as usual, peak demands country by country. Kind regards

Hello! We would like to inform you that we have made every effort to ensure AirVPN full and efficient operation during the pandemic caused by SARS-CoV-2. In order to reduce hazard and safeguard health, AirVPN staff and personnel work exclusively from home and worked from home well before the current situation appeared clearly as a pandemic Each member has a landline and one or more mobile lines, when possible in different infrastructures, to maximize likelihood to stay connected to the Internet 24/7 AirVPN system is more efficiently automated and basic functioning requires no manual interventions, even for several months (if kernel upgrades hadn't been necessary, we would have had servers uptime of 4 years or more) AirVPN inner staff members have now overlapping competences. Therefore if a key member, including a founder, is forced to stop working, the other ones can carry out his/her functions Emergency funds already secured in the past in different facilities as well as banks remain unaltered and ensure AirVPN financial health for a very long time even in very harsh scenarios. However, we would like to assure you that they are not needed at all currently, quite the contrary. In the last 10 days we have experienced a substantial increase in the growth of our customer base We have been informed by our most important partners and providers of housing and hosting in Europe, America and Asia they they are, and expect to, remain fully operational Kind regards AirVPN Staff

Hello! No doubts we are having higher than average bandwidth request in the last days, but Canada infrastructure is still used mainly at no more than its 40% capacity. Even in your very screenshot you can see that most servers are not even at 60% Thanks to our planned in the past redundancy we can still support much more bandwidth. in Canada. Kind regards

@curhen57 Hello! Roughly, in IPv4 MAC addresses (more in general link layer addresses) are obtained via ARP (Address Resolution Protocol) requests, which are necessary when a node must physically find the final destination node otherwise identified only by an IP address. So your router knows the MAC address of your computers network interface, your nearest ISP upstream point knows your router network interface MAC address (and not your computers network interface one) and so on and so forth. Our VPN servers don't know anything about MAC addresses of your computer, router... For a more rigorous definition and information please see for example: https://en.wikipedia.org/wiki/Address_Resolution_Protocol Kind regards

@dedo299 Hello! We're glad to know that you found out the "culprit" causing the wake up issue. Network Lock is a set of firewall rules preventing traffic leaks outside the VPN tunnel, including, but not limited to, leaks caused by unexpected VPN disconnection and those caused by processes binding to the physical network interface. In Hummingbird, Network Lock is on by default. Kind regards

@dedo299 Hello! Thank you very much. AirVPN staff and personnel are healthy and fully operational. We all work from home to reduce hazard as much as possible. We all have at least one landline and one or more mobile line, in different infrastructures when possible. Good luck to you too, and to San Francisco and the rest of the world. We're glad to know that the previous problem seems resolved. Hummingbird writes to stdout and stderr so you can re-direct the log and errors in any way you prefer, for example (if you want both of them in a single file): sudo ./hummingbird [...] myprofile.ovpn > /var/log/hb.log 2>&1 To append log, instead of overwriting it: sudo ./hummingbird [...] myprofile.ovpn >> /var/log/hb.log 2>&1 Maybe it can help us understand the other issue you mention. Kind regards

@iwih2gk Hello! A few remarks to your last message. 1) MAC address is never included in IPv4 packets. Not even our VPN servers can see your network interface MAC address in IPv4. Similar safeguards are nowadays applied in modern OS for IPv6 too (IPv6 packets do have a specific allocation space for a MAC address). 2) Data passed voluntarily by a browser to a web site can be blocked or altered, either in browser configuration or through dedicated add-ons. Examples include spoofing browser user agent (which includes Operating System etc.) (**), blocking fingerprinting through canvas by generating "noise" and randomizing different fingerprints for each stream (*), and working without any previous tracking cookie by cleaning cookies at each session and working in browser "private" mode. Such safeguards should be applied even when working inside a VM, if your threat model needs them. (*) Example: Canvas Defender for Firefox. "Instead of blocking JS-API, Canvas Defender creates a unique and persistent noise that hides your real canvas fingerprint" (**) Example: User Agent Switcher and Manager for Firefox. Kind regards

@dedo299 Thanks, please keep us posted, we would like to know whether it resolves the issue in your case too or not. Kind regards

Hello! Please check here: It means that no VPN server meets the combination of settings you have required. In your specific case: airvpn_server_whitelist: Acamar A possible explanation is that you have some setting that's not compatible with Acamar (an example would be cipher CHACHA20), or that Acamar was down at the time of the connection attempt. Try to enlarge the white list of servers. Kind regards

@arteryshelby It doesn't make difference, actually. But if M247 tells us it's in Berlin, we publish Berlin. If you prefer you can consider it in Frankfurt until our next investigation. Topic locked. Kind regards

@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