Staff

@misam Thank you. We are aware of the problem and we are investigating. It affects OpenVPN 3 main library as well, so we have dragged it into our fork. By searching the web, we have seen that the problem is very sporadic (we are failing to reproduce it, but we are analyzing every aspect anyway) but it has been reported on the main line library since 2014. The fact that we can't manage to reproduce it makes the whole investigation very hard. On your side, can you please verify whether you get the issue when you connect to entry-IP address THREE, both in TCP and UDP, and report your findings? We will inform the community on any news on the issue. Kind regards

Hello! If you connect in TCP mssfix is irrelevant because it refers to TCP packets in UDP tunnels only. Kind regards

Hello! We're glad to inform you that Hummingbird 1.0.2 has just been released. Hummingbird is a free and open source software by AirVPN for: Linux x86-64 Linux ARM 32 (example: Raspbian for Raspberry Pi) Linux ARM 64 macOS (Mojave or higher version required) based on OpenVPN3-AirVPN 3.6.3 library supporting CHACHA20-POLY1305 cipher on OpenVPN Data Channel and Control Channel. Hummingbird is very fast and has a tiny RAM footprint. AES-CBC and AES-GCM are supported as well. Version 1.0.2 uses new OpenVPN3-AirVPN 3.6.3 library. Important: if you build Hummingbird please make sure to align to AirVPN library 3.6.3. You can't build Hummigbird 1.0.2 with library versions older than 3.6.3. Hummingbird is not aimed to Android but you can have CHACHA20-POLY1305 on Android too: please run our software Eddie Android edition, which uses our OpenVPN3-AirVPN library. TCP queue limit If you connect over TCP, Hummingbird will set by default a minimum TCP outgoing queue size of 512 packets to avoid TCP_OVERFLOW errors. If you need a larger queue in TCP, the following option is now available from command line, in addition to profile directive tcp-queue-limit: --tcp-queue-limit n where n is the amount of packets. Legal range is 1-65535. We strongly recommend you to allow at least 512 packets as queue limit (default value). Larger queues are necessary when you connect in TCP and need a lot of open connections with sustained (continuous) but not necessarily high throughput, for example if you run a BitTorrent software. In such cases you can enlarge the queue as much as you need, until you stop getting TCP_OVERFLOW. It's not uncommon from our community as well as our internal tests to set 4000 packets queue limit to prevent any TCP overflow. If you connect over UDP, you can ignore all of the above. Network Lock Network Lock prevents traffic leaks outside the VPN tunnel through firewall rules. Hummingbird 1.0.2 widens --network-lock option arguments. The following arguments are now accepted: on | off | iptables | nftables | pf (default: on). If you specify on argument, or you omit --network-lock option, Hummingbird will automatically detect and use the infrastructure available on your system. Hummingbird picks the first available infrastructure between iptables-legacy, iptables, nftables and pf. Note: command line options, when specified, override profile directives, when options and profile directives have the same purpose. Binaries download pages Linux: https://airvpn.org/linux/#Hummingbird macOS: https://airvpn.org/macos/#Hummingbird Complete instructions https://airvpn.org/hummingbird/readme/ Hummingbird source code https://gitlab.com/AirVPN/hummingbird OpenVPN3-AirVPN library source code https://github.com/AirVPN/openvpn3-airvpn Changelog Changelog 1.0.2 - 4 February 2020 - [ProMIND] Updated to OpenVPN3-AirVPN 3.6.3 - [ProMIND] Added --tcp-queue-limit option - [ProMIND] --network-lock option now accepts firewall type and forces hummingbird to use a specific firewall infrastructure *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 1.0.1 - 24 January 2020 - [ProMIND] Updated to OpenVPN3-AirVPN 3.6.2 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 1.0 - 27 December 2019 - [ProMIND] Production release *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 1.0 RC2 - 19 December 2019 - [ProMIND] Better management of Linux NetworkManager and systemd-resolved in case they are both running - [ProMIND] Log a warning in case Linux NetworkManager and/or systemd-resolved are running *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 1.0 RC1 - 10 December 2019 - [ProMIND] Updated asio dependency *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 1.0 beta 2 - 6 December 2019 - [ProMIND] Updated to OpenVPN 3.6.1 AirVPN - [ProMIND] macOS now uses OpenVPN's Tunnel Builder - [ProMIND] Added --ignore-dns-push option for macOS - [ProMIND] Added --recover-network option for macOS *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 1.0 beta 1 - 28 November 2019 - [ProMIND] Added a better description for ipv6 option in help page - [ProMIND] --recover-network option now warns the user in case the program has properly exited in its last run - [ProMIND] NetFilter class is now aware of both iptables and iptables-legacy and gives priority to the latter *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 1.0 alpha 2 - 7 November 2019 - [ProMIND] DNS resolver has now a better management of IPv6 domains - [ProMIND] DNS resolver has now a better management of multi IP domains - [ProMIND] Minor bug fixes *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 1.0 alpha 1 - 1 November 2019 - [ProMIND] Initial public release Kind regards & datalove AirVPN Staff

Hello! mssfix n directive tells OpenVPN to fragment TCP packets larger than n bytes inside the UDP tunnel If the bad packets problems is caused by an MTU size (it could be smaller than 1500 bytes), mssfix will fix the problem totally, assuming that you find the correct size. You can empirically go down, by setting lower and lower n, at little steps, for example 25 bytes at a time. Start from 1450, then try 1425 if necessary, then 1400 and so on if necessary. mssfix directive makes sense only on connections over UDP. Note that the smaller the maximum size "n", the lower the throughput, so it is essential to find a correct balance and the highest possible value. If mssfix does not resolve the issue, then the cause is probably different. Can you tell us your Operating System exact version? Kind regards

Hello! We are glad to inform you that we have released a new version of OpenVPN-AirVPN library. OpenVPN-AirVPN library is used by Eddie Android edition and Hummingbird for Linux x86-64, Linux ARM 32, Linux ARM 64 and macOS. The library provides several new features, such as CHACHA20-POLY1305 cipher on both Control and Data Channel, and fixes critical bugs from the master line. Please check the changelog. OpenVPN3-AirVPN library is free and open source software available here: https://github.com/AirVPN/openvpn3-airvpn Kind regards AirVPN Staff Changelog https://github.com/AirVPN/openvpn3-airvpn/blob/master/CHANGELOG.txt Changelog 3.6.3 AirVPN - Release date: 29 January 2020 by ProMIND - [ProMIND] [2020/01/29] Added TCP queue limit override to client configuration *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 3.6.2 AirVPN - Release date: 24 January 2020 by ProMIND - [ProMIND] [2020/01/24] openvpn/ssl/proto.hpp: set_ncp_disable() fixed bug for ncp-disable override which caused profile setting to be ignored *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 3.6.1 AirVPN - Release date: 28 November 2019 by ProMIND - [ProMIND] [2019/11/28] openvpn/tun/builder/base.hpp: Added virtual method ignore_dns_push() to TunBuilderBase class - [ProMIND] [2019/11/28] openvpn/tun/client/tunprop.hpp: added DNS push ignore to method add_dhcp_options() *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 3.3.2 AirVPN - Release date: 10 October 2019 by ProMIND - [ProMIND] [2019/09/04] fixed bug in openvpn/tun/linux/client/tunsetup.hpp: changed if(conf->txqueuelen) to if(conf->txqueuelen > 0) which made linux connection to fail - [ProMIND] [2019/09/04] openvpn/tun/linux/client/tuncli.hpp: added initialization to TunLinux::Config::txqueuelen - [ProMIND] [2019/09/10] openvpn/tun/linux/client/tunsetup.hpp: removed remove_cmds->execute(os) call in establish which prevented reconnection to work properly - [ProMIND] [2019/09/10] openvpn/tun/linux/client/tunsetup.hpp: removed connected_gw member and related code which prevented reconnection to work properly - [ProMIND] [1019/10/10] openvpn/client/cliopthelper.hpp: added method getRemoteList(). Returns remoteList member with list of profile's remote entries - [ProMIND] [2019/10/10] client/ovpncli.hpp: added RemoteEntry structure to reflect profile's remote entries - [ProMIND] [2019/10/10] client/ovpncli.hpp: added remoteList member - [ProMIND] [2019/10/10] client/ovpncli.cpp: OpenVPNClient::parse_config now assigns remoteList member with values of ParseClientConfig.getRemoteList() *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 3.3.1 AirVPN - Release date: 31 August 2019 by ProMIND - [ProMIND] [2019/08/06] Added cipher override to client configuration - [ProMIND] [2019/08/06] Added ncp disable override to client configuration *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Changelog 3.3 AirVPN - Release date: 13 July 2019 by ProMIND - [ProMIND] [2019/06/02] Forked master openvpn3 repository 3.2 (qa:d87f5bbc04) - [ProMIND] [2019/06/06] Implemented CHACHA20-POLY1305 cipher for both control and data channels - [ProMIND] {2019/07/10] Implemented ncp-disable profile option

Hello! We would like to check it out as this is not what we experience: what is the Shield version in your device? By chance, are you using the brand new remote command from nVidia (the one with back lighted keys)? We ask because it's the only remote command we don't have in our testing systems and Eddie was released when it did not exist. Important: by using profiles you will not need a Master Password. Kind regards

Hello! Currently Netflix is not accessible from our infrastructure. We are working on the problem. As usual, we can't promise anything on such peculiar subject. The proper source of information, which is frequently updated, is our post in the correct forum: Kind regards

@HannaForest Hello! Yes, that's correct: airvpn.org is with Ovh in France. Kind regards

Hello! Entering a Master Password in Eddie Android edition does not require a mouse on nVidia Shield and Shield Pro. You can enter it via the remote control or the joypad. You can also use a profile to skip any Master Password requirement. Instructions for Eddie Android edition are here: https://airvpn.org/forums/topic/29660-using-airvpn-with-eddie-client-for-android/ Kind regards

Hello! We have good relations both with OvH and M247. The problem in France is different, we have explained it many times so we will not explain it again here in details, and is related to the illegal framework of the country pertaining to data retention and the inability of the European Commission to incisively start an infraction procedure against France (and Italy as well). As we already fight the illegal position of other EU countries on data retention we need to focus resources. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Riga, Latvia, is available: Felis. The AirVPN client will show automatically the new server; if you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Felis supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/felis Felis brings for the first time 1 Gbit/s connections availability in Latvia meant to replace in the very near future all the current 100 Mbit/s ports and lines. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Berlin, Germany, is available: Cujam. The AirVPN client will show automatically the new server; if you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Cujam supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/cujam Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

@nick75 Hello! Yes, actually this is planned, please stay tuned. :) Kind regards

Hello! All AirVPN servers support IPv6 except Kitalpha and Metallah, which are operational inside datacenters that do not have an IPv6 infrastructure at all. Unfortunately, intermittent IPv6 related problems affect the servers you mentioned. Such problems are caused by IPv6 "black outs" in the respective datacenter. We have already contacted datacenter technicians asking for a problem resolution. Kind regards

Version 2.18.7 (Wed, 29 Jan 2020 13:54:35 +0000) [bugfix] - Update notification for beta versions [bugfix] - Windows - Message when driver installation is denied [bugfix] - macOS - Fix of error "hummingbird not allowed: Not owned by root". [bugfix] - Linux - Fix of error "Client not allowed: [...] parent process (spot mode)", CLI edition with sudo [bugfix] - Fix of error "Failed to connect to ... port 89: Connection refused" when using Hummingbird in SSL/SSH mode [bugfix] - Better exception management to avoid some crash (especially when related to Mono) [bugfix] - Linux - Arch deployment and AUR management [bugfix] - Tor Cookie/Password detection in every supported OS [bugfix] - Updated 'curl' binary in Windows and CA file [change] - macOS - Minor info.plist update in CLI edition [change] - Windows/Linux - OpenVPN Management skip [change] - In 'Latency mode', now load and users have minor impact on score.

@usefulvid Thank you. We have reviewed the four tickets (all by the same user) which in your opinion hint to bad support and we don't agree with you. They have all been handled very professionally as far as we can see, and in our opinion, even when the problem of the user was unrelated to AirVPN and therefore totally out of the scope and competence of the support team. Kind regards

@monstrocity Hello, we're very glad to see that the problem is resolved. 2048 packets make the output queue huge, but actually it is proportional to the amount of concurrent connections limit you have set in your torrent software. qBittorrent comes with a limit of 500 by default. The other error you report pertains to a disconnection, unrelated to TCP_OVERFLOW. If you get such disconnections more often when you torrent, please warn us. For the readers: overflow in the TCP output queue is a problem that does not exist in UDP. Kind regards

@56Kmodem @monstrocity Updated thread with a tested solution which hopefully will be confirmed by you both is here: Kind regards

@monstrocity Please increase the maximum amount of packets allowed in the TCP queue with directive tcp-queue-limit n (n is the amount of packets) according to the amount of concurrent, global TCP connections your system needs when you run a BitTorrent software. OpenVPN 3 default limit is 64 packets. For example, add to your profile the following line: tcp-queue-limit 256 Please test again and check whether the problem is resolved. Of course consider to increase the amount of packets beyond 256 if you see the problem persisting. Your feedback is very much appreciated. Kind regards

@inradius It's exactly the contrary. Canada servers rarely need to provide more than 33% bandwidth they are capable of. Even considering the 40% you mention, our infrastructure in Canada is largely OVER sized with enormous availability of traffic and bandwidth. On 90% of the time, you have 18 Gbit/s availability in Canada which is never used by anyone. The issues you mention can not be related to servers available bandwidth, you must have some problem on your side or something else, outside our servers, is the cause of the problem with YouTube etc. Adding servers would be perfectly useless in your case. You might like to open a ticket to investigate the issue more properly. Kind regards

@usefulvid 1) CHACHA20 is not experimental on the client side but yes, it is experimental on the server side because OpenVPN 2.5 is still not in stable phase, although it was promised for November/December 2019. That's why we prefer to clarify it. 2) We don't know why they stick to obsolete versions. OpenVPN 2.4 without tls-crypt supports OpenVPN up to 2.2 so it is not a problem for Windows XP and onwards... OpenVPN 2.3.x should not be necessary anymore for any backward compatibility. Thanks for the answers. Staff account does not have PM enabled for flood reasons, please contact us at your convenience either at info@airvpn.org or open a ticket with usefulvid subject (or from your usefulvid account). Kind regards

@usefulvid Are we correct in noticing that no mention of CHACHA20-POLY1305 (boosting performance of non AES-NI supporting devices and adding dramatically battery life of battery based devices) has been done? If we are right, has it been omitted because it is not considered relevant, or for some other reason? Also, is the fact that AirVPN develops OpenVPN 3 not perceived as relevant by your audience? Candid questions whose answers may be useful to us, but of course feel free to not answer. Important disclaimer for the readers: the author of the review has never been paid, either directly or indirectly, by AirVPN. Congratulations for being one of the few who did not ask for money "or else...". Kind regards

@usefulvid Please point us to the ticket that has not been answered properly. Kind regards

@giganerd Hi, it should be "impossible" and not "more difficult" by deep inspecting the packets. Are you aware of any new method that can find out you're using OpenVPN by only analyzing the flow (i.e. without knowing that on the destination IP address OpenVPN answers)? Kind regards

@monstrocity Hello! Bug detected and under investigation. It involves all versions of OpenVPN 3 library (not only our fork unfortunately) so it must be something we have been dragging with us since the very beginning, OR (worst case scenario) something related to asio library (hopefully not). If you have the option to use UDP, please do it, otherwise stay tuned, we have given very high priority to the bug. Kind regards