Staff

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

@dr_kristau Thanks, let us know. With Wireguard the performance loss you get with CHACHA20 in an AES-NI supporting CPU is more than compensated by the fact that Wireguard runs in the kernel space, while OpenVPN in the userspace (and does not scale in multicore processors). You will not get the same Wireguard performance with OpenVPN CHACHA20 in your Celeron, because of that very fact. In our infrastructure, anyway, even with Wireguard, you should not expect more than 400-500 Mbit/s, because no server usually has more than 800-900 Mbit/s free (things might change in the future with 10 Gbit/s line per single server). Kind regards

@dr_kristau Hello! it's strange that the router has a peak of 85 Mbit/s in upload and 17 in download. It makes us think about traffic shaping in download. Do you have your ISP traffic shaping (or traffic management) policy? By the way, with that configuration OpenVPN 2.5 will not negotiate CHACHA20 on the Data Channel. If you check the log, you should see that you're still with AES-256-GCM. Modify in the following way: delete line cipher CHACHA20-POLY1305 add lines: data-ciphers CHACHA20-POLY1305 data-ciphers-fallback AES-256-CBC Check in the log that OpenVPN 2.5 uses CHACHA20 in the Data Channel. You should see: Yes. 310 Mbit/s with an i7 and AES-256-GCM is expected. It means 620 Mbit/s on the server and it's more or less what we detect from a fiber line in Italy. We managed to beat that performance on the client side toward our VPN servers only from dedicated lines of dedicated servers. Even 85 Mbit/s with the Celeron in AES-256-GCM sound quite reasonable. It remains to be seen why the router in download becomes so sluggish (17 Mbit/s instead of 85 Mbit/s). Finally, feel free to let us know the performance you will get with CHACHA20, we're curious to see what happens with a Celeron. Kind regards

@dr_kristau Hello! Yes, AES-256-GCM is computationally hard for non AES-New Instructions supporting CPUs. Also consider that OpenVPN 2 does not scale and runs in a single thread of a single core, in the userspace. You have a very slight performance improvement when OpenVPN is linked against mbedTLS and not OpenSSL, but it's not really essential.. With your Celeron you should get significant performance improvement with CHACHA20-POLY1305 cipher for Data Channel. For that, you will need OpenVPN 2.5 or higher version (OpenVPN 2.5 stable version was released yesterday). We have completed deployment of OpenVPN 2.5 on all servers now and while we restart the daemons, more and more VPN servers will offer CHACHA20-POLY1305 on both Data and Control Channel. At the moment, you can have CHACHA20-POLY1305 on the servers marked as "Experimental". Remember that OpenVPN 2.5 or higher version is required, as older versions do not support CHACHA20 on Data Channel. Kind regards

Hello! TLS 1.3 is only available on experimental servers, and only on those servers where OpenVPN 2.5 is linked against OpenSSL, because mbedTLS does not support TLS 1.3. When we deploy OpenVPN 2.5 on all servers, it will be linked against OpenSSL, so TLS 1.3 will be available on all servers Keep in mind anyway that, so far, TLS 1.3 with OpenVPN is inessential. Kind regards

Hello! On a 1 Gbit/s fiber line in Italy which does not suffer traffic shaping we record about 330 Mbit/s with Hummingbird and an Intel i7 (in a Fedora 32 system), with AES-256-GCM on Data Channel and connections to Belgium and the Netherlands servers. Hummingbird uses OpenVPN3 linked against mbedTLS, but we record same performance with OpenVPN 2 linked against OpenSSL. Similar, consistent speeds are recorded by many users. Consider that we have in particular a couple of customers who connect only from dedicated servers and keep their speed (with OpenVPN 2 or 3) constantly at 480 Mbit/s (i.e. 960 Mbit/s on the server). What are your system, CPU, OS? Are you sure that your ISP does not enforce traffic shaping and that your CPU is not the bottleneck? Have you tested several servers to maximize likelihood of good peering between your ISP and our transit providers? Kind regards