Staff

@dragoworld235 Hello! Changing Eddie to make it run OpenVPN 2 is a problematic matter, because OpeNVPN 2 is not a library, while OpenVPN3 is. By avoiding to run an external binary Eddie Android edition complies to security best practices as well as Google requirements in latest API. Anyway OpenVPN3-AirVPN library is not OpenVPN3. It's a fork which is 90 commits ahead of OpenVPN:master and had many important bugs fixed. An updated Eddie Android edition using our latest library version might be a Christmas present to you all, while you will see very soon an updated Hummingbird (which also calls OpenVPN3-AirVPN library) for Linux and macOS. Kind regards

@samaw80 Hello! We apologize for the inconvenience, which has been caused by Apple notarization. You can quickly resolve the issue by downloading and running Eddie 2.19.5. To do that, in Mac download page https://airvpn.org/macos click the button "Click here" just under the sentence: If you run older than macOS Catalina systems, please download latest Eddie 2.19 beta version You will be brought back to the download page, pointing to Eddie 2.19.5 and its specific notarization for systems older than Catalina. Kind regards

@sooprtruffaut Thank you! In which system do you need CHACHA20 for performance improvement? Kind regards

Hello! We're sorry, it's not yet implemented. You can already test CHACHA20 from Eddie Android edition and Hummingbird, anyway, not only from OpenVPN 2.5. If you have any issue please let us know. Kind regards

@Shiver Me Whiskers Hello! Yes, today Eddie 2.19.5 with wintun support for Windows was also released. 😎 Thank you, enjoy AirVPN! Kind regards

Version 2.19.5 (Wed, 04 Nov 2020 11:22:24 +0000) [bugfix] Minor bugfixes [bugfix] Occasionally wrong order in DNS restoring [change] OpenVPN 2.5.0 - Hummingbird 1.1.0 [change] Minor changes The primary objective of this version is OpenVPN 2.5.0. Other issues are still under investigation, thx. AUR (Arch repository) will be updated ASAP.

Hello! Thank you! No, "Line issue" may hint to other problems as well. We will try to be more precise in the future by editing by hand the status. Now all the servers in Maidenhead are fully operational. Kind regards

Hello! We're very glad to announce all VPN servers progressive upgrade to Data Channel CHACHA20-POLY1305 cipher and TLS 1.3 support. UPDATE 18-Nov-2020: upgrade has been completed successfully on all AirVPN servers. The upgrade requires restarting OpenVPN daemons and some other service. Users connected to servers will be disconnected and servers during upgrade will remain unavailable for two minutes approximately. In order to prevent massive, simultaneous disconnections, we have scheduled a progressive upgrade in 15 days, starting from tomorrow 5 Nov 2020. Please see the exact schedule at the bottom of this post, in the attached PDF file. Servers marked as "OK" have been already upgraded and you can use CHACHA20-POLY1305 with them right now. When should I use CHACHA20-POLY1305 cipher on OpenVPN Data Channel? In general, you should prefer CHACHA20 over AES on those systems which do not support AES-NI (AES New Instructions). CHACHA20 is computationally less onerous, but not less secure, than AES for CPUs that can't rely on AES New Instructions. If you have an AES-NI supporting CPU and system, on the contrary you should prefer AES for higher performance. How can I use CHACHA20-POLY1305 on AirVPN? CHACHA20-POLY1035 on Data Channel is supported by OpenVPN 2.5 or higher versions and OpenVPN3-AirVPN library. In Eddie Android edition, open "Settings" > "AirVPN" > "Encryption algorithm" and select CHACHA20-POLY1305. Eddie Android edition will then filter and connect to VPN servers supporting CHACHA20-POLY1305 and will use the cipher both on Control and Data channels. In our web site Configuration Generator, after you have ticked "Advanced Mode", you can pick OpenVPN version >=2.5, and also select "Prefer CHACHA20-POLY1305 cipher if available". If you're generating a configuration file for Hummingbird, select OpenVPN3-AirVPN: the configuration file needs to be different, because some new directives of OpenVPN 2.5 are not supported in OpenVPN3, and Hummingbird is based on OpenVPN3-AirVPN. In Eddie desktop edition, upgrade to 2.19.6 version first. Then select the above mentioned option. However, most desktop computers support AES-NI, so make sure to check first, because using CHACHA20-POLY1305 on such systems will cause performance harm when you go above 300 Mbit/s (if you stay below that performance, probably you will not notice any difference). Also note that if your system does not have OpenVPN 2.5 or higher version you will not be able to use CHACHA20-POLY1305. If you wish to manually edit your OpenVPN 2.5 profile to prefer CHACHA20 on Data Channel when available: delete directive cipher add the following directive: data-ciphers CHACHA20-POLY1305:AES-256-GCM Pending Upgrade Server Schedule Kind regards and datalove AirVPN Staff

Hello! They are not down, they are in "yellow state" for aggressive DDoS. The anti-DDoS filter works, but sometimes filters out even proper connections, so we prefer to recommend different servers. It's up to you, the servers are not closed and accept connections in all modes. If you experience issues, it's the anti-DDoS filter. The datacenter will lift the filter when the attack ceases (the only alternative is null-routing the servers IP addresses, in such a case the servers will be of course completely closed). Kind regards

Hello! It's the Data Channel key re-negotiation over the Control Channel via Diffie-Hellman Exchange. See also Perfect Forward Secrecy: https://en.wikipedia.org/wiki/Forward_secrecy You can lower the re-negotiation time on your client side with directive reneg-sec n, where n is in seconds, but you can't increase it and you can't disable forward secrecy (anyway you don't want to disable it). OpenVPN re-negotiates Data Channel key by using overlapping time windows. During the negotiation, the previous key is used for any packet flow, so you will not notice any communication breakdown. When the message "killed expiring key" appears, it means that the negotiation completed successfully and the previous key is not used anymore. AirVPN uses unique DH keys. Each VPN server has a different and unique key. DH key size is 4096 bit. Kind regards

Hello! Not by itself, but you can connect Hummingbird locally after you have established a tunnel by stunnel to our servers. In order to do so please see here: https://airvpn.org/ssl/ Please test connections in TLS Crypt and TCP first. TLS crypt, combined with TCP; has mainly made OpenVPN over stunnel obsolete: it has the same block circumvention abilities and provides higher performance. Only if TLS Crypt fails test OpenVPN over stunel (if it fails too, test OpenVPN over SSH). https://airvpn.org/ssh Note: if you are not in a restrictive network do not add a second tunnel, which decreases performance, and work in UDP. which is more efficient for OpenVPN. Kind regards

Hello! Yes, that's the failover, by definition, but the setup in the linked article supports load balancing too. On a second thought, it seems fine even for your failover needs, unless you need to get out on the Internet only with one specific IP address from time to time. Kind regards

Hello! Yes, we are aware of the issue. You are almost right. systemd-resolved can work in different modes. One of those modes is not compatible with the DNS handling performed by Hummingbird and Eddie. Same problem with Hummingbird. Please see here for a momentary workaround and a more detailed insight on the specific working mode, causing the issue, of systemd-resolved now enabled by default on Fedora 33: https://airvpn.org/forums/topic/48252-eddie-checking-dns-failed/ The workaround suggests to disable systemd-resolved, but in reality you could also keep it up but re-configure it to work in any "resolv.conf" compatible mode. Kind regards

Hello! Halloween 2020 deals will end at the midnight between the 2nd and 3rd of November, UTC. Kind regards

Hello! Yes, by a community member, for pfSense 2.4.5. You can find it linked at the beginning of the instructions. For your comfort: https://nguvu.org/pfsense/pfsense-baseline-setup/ Also do not miss the following one too: https://nguvu.org/pfsense/pfsense-multi-vpn-wan/ Home page with so many interesting articles: https://nguvu.org/ Kind regards

@McLoEa Good to know, thank you for the info. We are checking how to address the issue with systemd-resolved working in that specific mode. Kind regards

@jollyroger Hello! That's correct, pre-release code is private. You can check changelog here: https://eddie.website/changelog/?software=client&format=html Kind regards

@lisaAweber Hello! We want to reply for other readers who have similar requests for dozens of different services of various kinds. In this case we can't verify because the app is a little shady, as @giganerd pointed out, but you can test yourself: you can get a three days free trial with no commitments simply by asking for it (open a ticket from your account). Kind regards

@McLoEa Hello! We don't know if it was you who pointed the support team to the following article in a ticket: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VPACQVWRG5HCWRPBIOTBAENRT6V6PRA4/ If not, the relevant part is: systemd-resolved has various operational modes and Eddie, at the moment, can NOT handle properly the "on link" mode bypassing resolv.conf and relying on nss-resolve. In Fedora 33 systemd-resolved is configured by default in a way that Eddie does not handle correctly. Hummingbird and Bluteit, in the AirVPN Suite, can handle correctly any systemd-resolved operational mode. Disabling systemd-resolved, anyway, should resolve any issue with Eddie and OpenVPN DNS push. In a few words, the key is going back to handle DNS via resolv.conf file as usual. If you wish to disable systemd-resolved: sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved IMPORTANT: create a new resolvc.conf file and/or restart network-manager service if necessary. Kind regards

@Krebbin Hello! We're very glad to know it. Eddie Android runs very well on a Sony Bravia TV X900 we tested, and a couple of users confirmed it works fine in another model (X950H). However, we could not manage to test it in other Sony TVs unfortunately. Can you specify your model, if you don't mind, just to add it in our db? What Android version does it run? Kind regards

@jsp21c Hello! Yes, your wait is nearly over. Eddie 2.19.5 is currently tested internally and resolves incompatibility with Windows wintun. It will be packaged with OpenVPN 2.5. Stay tuned. Kind regards

@pop22 Hello! Which Mono version do you have in your system? Try to delete file ~/.config/eddie/default.profile while Eddie is not running and check whether the problem persists or not. From a CLI: rm ~/.config/eddie/default.profile You will need to re-enter your credentials when you re-start Eddie. If the problem remains, can you please test (if you haven't already done so) the AppImage (click "AppImage" icon in the usual download page)? Quick reference to run an AppImage: https://itsfoss.com/use-appimage-linux/ Kind regards

@dr_kristau Good! And congratulations, 571 Mbit/s is a new, absolute, all time client record in our service! You and our server Comae managed to beat Wireguard performance too, that's really something. OpenVPN 2.5 has been released a couple of days ago. Deployment on all servers has been completed but before restarting them all we need to resolve a very annoying problem: apparently a bug which was not there in any beta version and in RC1, but appeared now in the final release. The bug compromises CHACHA20 negotiation on the Data Channel between OpenVPN3 and OpenVPN 2.5 (but it's fine between OpenVPN 2.5<->OpenVPN 2.5). Once we find out, isolate and fix the bug (either on client or server side) we will activate OpenVPN 2.5 on all servers and you will be able to use CHACHA20 on all of them. It's a matter of days, we hope. Kind regards

@carlsaj Hello! Watch out, your account panel shows that you have not forwarded remotely any port. You can do that in "Client Area" > "Ports" (after you have logged your account into the web site). See also: https://airvpn.org/faq/port_forwarding/ Kind regards

@dr_kristau Hello! Thanks for the detailed report. Yes, Wireguard with CHACHA20 peaks 541 Mbit/s whereas OpenVPN peaks 400 Mbit/s. We can't explain why, in OpenVPN, CHACHA20 is faster than AES even in an i7 (which supports AES-NI). AES should be faster. Maybe it was due only to the momentary network heavy usage you mention? Is the library linked by OpenVPN enabled to AES-NI (if it's OpenSSL, it should be by default in any recent version)? Kind regards