Staff

@misam @hawkflights We are still struggling to reproduce the issue. We have been testing for dozens of hours with a forced re-keying every 5 minutes, initiated by the client side, and no problems have arisen. Can you please do the same on your machines, where the problem seems to occur frequently, with the same profile you have been using so far, but with the addition of the following directive: reneg-sec 300 In this way it's the client that starts the re-keying request (every 300 seconds), so you should see a re-keying every 5 minutes. You can put the directive anywhere (as a single line, followed by RETURN) within the first block of directives. We would like to compare whether in your systems the problem occurs with the same frequency (or at all) when it's the client to ask for re-keying. Thank you in advance. Kind regards

@arteryshelby It seems that the datacenter brings a server offline as soon as it receives any complaint. So a quick way to put any server running in their datacenter down is simply creating a complaint or fabricating a fake complaint for anything, and the server will go offline without any verification. Under these conditions it is of course impossible to operate a server for almost anything. Kind regards

@sapience If nothing listens to port 8080 of your localhost, it's strange that you have forced Eddie to connect to it. A system report will let us see the complete Eddie configuration to confirm or not that it has been misconfigured and possibly it will provide us with more clues to understand the source of the issue. To generate a system report please click "Logs" from Eddie's main window, click the LIFE BELT icon, click the Copy all icon; then send the report to us by pasting into your message. Please make sure to generate the system report after the problem has just occurred. Kind regards

@Ledkfr We would then suspect that your ISP enforces traffic shaping after a certain traffic volume threshold exchanged with a VPN server and/or on a time basis, but that's not possible because you don't have the problem when you connect via Ethernet, so we still think that the problem is related to WiFi. Another option to consider is a problem with WiFi on the final computer network interface (try to update its driver if possible): you don't see the problem with Ethernet because the network card is different, but on WiFi after a certain period of time the problem is triggered by something unknown and maybe related to OpenVPN and/or UDP. Other than that we can't think of any other rational explanation unfortunately. Kind regards

Hello! You can consider to use an Ethernet connection, if it's a viable option. If not, it's worth to test different WiFi channels, especially if you have neighbors using WiFi as well. Changing channel may solve every problem, but not all routers let you change manually channel unfortunately. Please see also here: https://www.extremetech.com/computing/179344-how-to-boost-your-wifi-speed-by-choosing-the-right-channel Kind regards

Hello! Please make sure that you have Raspbian 10 or higher version, then can you please check what happens with Hummingbird for Raspbian? Hummingbird is a stand alone binary. If any issue persists, feel free to post the log, both from Eddie and Hummingbird. https://airvpn.org/linux/#Hummingbird Kind regards

@giganerd Yes of course, it's safe. We have different backend servers accessed by the web sites, so when .org and .info frontend servers contact (indirectly) those backend servers, and some problem is occurring on a specific one, we can set them not to contact the same one (otherwise you would see the identical problem). Kind regards

Hello! Do you run Eddie or Hummingbird? What is the installed distribution, Raspbian 32 bit or some Linux 64 bit? Kind regards

@hawkflights Hello! OpenVPN tries to re-connect by default, as you have noticed. To make it rotate VPN servers when a connection fails, you can consider to add multiple remote lines in your profile. When a connection attempt fails, OpenVPN will pass to the next remote line, trying the next server in the "remote" list. Should you wish to start with a random server, add also remote-random directive; OpenVPN will rotate servers in sequence as usual, but it will start from a random server at startup. Kind regards

@pictor13 Hello! Can you tell us your exact macOS version as well as the Eddie version you run? Please consider to test also Eddie 2.18.7 beta if you haven't already done so. Eddie 2.18 resolves several issues that Eddie 2.16 may have especially in macOS Catalina. Please see here to download Eddie latest beta version: https://airvpn.org/forums/topic/45326-eddie-desktop-218beta-released/ Kind regards

Hello! Our web site is very frequently and heavily flooded and we have reached, we think, a good balance between flood protection and web site usability. We will keep trying to improve it in order to make things better and keep the web site accessible even in those cases it is still not, without adding annoying barriers and permanent blocks. It must be said that usually you don't even see when a flood is ongoing, except for some sluggishness in loading pages, but at the same time of course anything can be made better in general. It is also true that flood events have become more frequent in the last month. Furthermore, we will also verify whether some of the interruptions you mention are really caused by floods or by something else. Kind regards

@Arnonym2000 Hello! Can you please check the hummingbird file flags? An option to consider is that hummingbird lacks the x (executable) flag for other users, including the user that tries to run it, in your case (it might have happened if you have decompressed the tarball without preserving file attributes). From a terminal, after you have entered the directory where hummingbird is inside: ls -l Kind regards

@sapience Hello! What do you have listening to port 8080 of localhost (127.0.0.1)? According to the log, connection to it is refused. It seems that Eddie is configured to connect to a local proxy listening to port 8080, but that proxy refuses connections (or it is not running?), or a firewall blocks curl packets to your proxy. Can you also post a system report generated by Eddie? Kind regards

Hello! Can you please test Eddie 2.18.7 beta, check whether the problems are resolved or not, and at your convenience give us a feedback? Please see here to download Eddie's latest beta release:Kind regards

@NinjaThunderbolt Hello and thank you for your report! Yes, Network Lock, either on Eddie or Hummingbird, will set its own rules, otherwise it could not guarantee traffic leaks prevention outside the VPN tunnel. When you write "a lot more" disconnections, is it compared to OpenVPN 2? Can you also post the log showing the disconnections? Kind regards

Hello! Quick update: it is not very useful to compare OpenVPN 2 behavior because we have just ascertained that OpenVPN 2 completely lacks any implementation for such an error. Under this aspect, it's a very good thing that OpenVPN 3 is stricter. Kind regards

@Lee47 Hi, with Asus MerlinWRT you should be able to forward and pre-route packets from the tun interface of the router to the final IP address and port in your network through iptables rules. You can check whether the following guide is applicable to your firmware (access to iptables is necessary): Kind regards

@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