Staff

@newairvpnuser Hello! Mobile ISPs routinely shape at least UDP traffic. From tests with 6 major mobile ISPs in Italy, Germany, UK and Spain, we have found that 100% of them enforce traffic shaping, of various types. Traffic shaping against UDP is less common, but not infrequent, with landline ISPs. A new extreme shaping which is terrible is shaping against anything that can not be identified as HTTP/HTTPS/privileged services; it is also getting not infrequent. Try to switch to TCP and make sure to test various servers in various locations. Your device processor is, in theory, capable to encrypt/decrypt at least 50 Mbit/s of an AES-256-GCM flow, and much more with CHACHA20 (more than 70 Mbit/s), so traffic shaping enforced by your ISP is an option to consider according to your report. Consider to connect in TCP, and also test CHACHA20-POLY1305 cipher, which is supported by Eddie Android edition. Air VPN servers which support CHACHA20 are highlighted in yellow with the phrase "Experimental ChaCha20" in the servers monitor https://airvpn.org/status Anyway, once you tell Eddie to use CHACHA20, it will show and connect to only those Air VPN server which support CHACHA20. Select Eddie's "Settings" view, expand "AirVPN", tap "Encryption algorithm", select "CHACHA20-POLY1305" and tap "OK". Also tap "Default protocol", tap "TCP" and tap "OK". Tap "Quick connection mode", select "Use default options only" and tap "OK". Then test a quick connection and verify whether you get better performance or not. IMPORTANT: if you select manually servers in the "VPN servers" view, you need to specifically set "TCP" in the "AIRVPN SERVER" settings menu, because this setting is distinct from the quick connection mode configured protocol, while "Encryption algorithm" is kept always global. Kind regards

@monstrocity OVPN files have no restrictions in any way. Generate the proper file with the Configuration Generator (tick "Advanced Mode" to see all the available connection modes) or just edit your current profile with any text editor and replace the port you have in the remote directive with 41185. Kind regards

@monstrocity Thank you for your report. Interesting outcome. To kill Hummingbird gracefully send it a kill signal 15 (SIGTERM): sudo kill `pidof hummingbird` If Hummingbird is not detached from a terminal emulator you can also press CTRL-C on that to stop Hummingbird gracefully. Please see also: https://airvpn.org/hummingbird/readme/ Kind regards

Hello! That may happen, unfortunately, even with owned servers housed in any datacenter. Our servers do not keep any account data but they might be monitored in real time with external "black" boxes which can not be detected by the server itself (in practice they sniff traffic just outside the server without interfering with the server itself). However, if someone tries to tamper a server in any other way, the server will not start, because each restart will cause a lock out by our system. That VPN server must be validated manually by AirVPN management to be accepted again in the infrastructure, so if anything weird happens it will remain locked out. To defeat an adversary that monitors incoming and outgoing packets of a VPN server, and tries to correlate them, please see here: https://airvpn.org/forums/topic/54-using-airvpn-over-tor/?do=findComment&comment=1745 Kind regards

@monstrocity Yes, correct! Kind regards

@monstrocity Please add it in the first block of directives of the ovpn file "AirVPN_Japan_TCP-443.ovpn" Open the file with a text editor, add the following line, FOR EXAMPLE just under the line beginning with "remote": reneg-sec 300 (press ENTER after it, it must be a stand alone line) and save the file. Then re-run Hummingbird like you already did, but without the --reneg-sec option. Note whether the re-keying error occurs as usual or not. Thanks in advance! Kind regards

@monstrocity Thanks. Can you add now reneg-sec 300 directive, run Hummingbird alone, and check whether anything changes? See also: Kind regards

@monstrocity Please upgrade to Hummingbird 1.0.2, use it alone (without Eddie) and check whether the same problems occur. Also compare with Eddie + OpenVPN 2.4: do you see the same errors or not? Kind regards

@adams.j Hello! Can you please test a connection over TCP (you can set it in the "Settings" view or in the single servers view) and check whether the problem persists or not? Just in case your ISP messes with UDP (not uncommon situation with mobile ISPs). Kind regards

@misam Default value is 3600 seconds (1 hour). And actually you can see that you always get the error you mentioned exactly n hours after your initial connection, with n a positive integer, an additional confirmation that the problem specifically occurs just before or during a re-keying. The first block of directives is placed on the top of the text file. We mean, do not insert the directives somewhere in the middle of certificates, keys or <> blocks. Kind regards

@arteryshelby Hello! We're afraid no solution is possible, as they have not the ability or the will to check whether a notice is bogus or not. We are looking for alternatives in Lithuania and in other countries in the Baltic region, including Estonia and Finland. Kind regards

@giganerd @Ansuz Eddie tries to flush DNS cache by checking various processes and acting accordingly. nscd should be detected and restarted by both Eddie 2.16 and Eddie 2.18 (exactly with the purpose to flush DNS cache), we will check the anomaly. What is the exact distribution where the anomaly has been detected? Kind regards

@sapience Nothing wrong with Eddie configuration, so it remains unexplained why Eddie tells curl.exe to download AirVPN data from localhost. Try the following: - make sure that Eddie is not running - rename C:\Users\Server\AppData\Local\AirVPN\default.xml to default.xml.old (it's Eddie's configuration file) - re-run Eddie. When Eddie does not find the configuration file, it creates a new one with default settings - try a connection and check whether the problem persists or not If the problem persists, please test Eddie 2.18 beta 7, please see here to download it: https://airvpn.org/forums/topic/45326-eddie-desktop-218beta-released/ Kind regards

Hello! Turning off encryption is not possible. Picking less onerous ciphers is possible. You can see on the https://airvpn.org/status page, by clicking the name of a server, the supported ciphers both for the Control and the Data Channel. The cipher for the Control Channel is essentially irrelevant for performance, but cipher for the Data Channel is. For the Data Channel, the servers propose AES-256-GCM. On your OpenVPN client, add the directives ncp-disable and cipher <the cipher you want> For example, if you want AES-128-GCM: ncp-disable cipher AES-128-GCM If your system does not support AES-NI (New Instructions) then you can have relevant performance boost with CHACHA20-POLY1305. Currently five Air VPN servers are running OpenVPN 2.5 offering CHACHA20, you can recognize them because they are marked yellow with "Experimental CHACHA20" description (in Canada, USA, the Netherlands, Singapore). When OpenVPN 2.5 is released as a stable version, we will progressively update all VPN servers to support CHACHA20. So, in case you need CHACHA20 because your system or CPU does not support AES-NI (note that it's not enough that the CPU supports AES-NI: even the SSL library linked by OpenVPN must support it), you can use the cipher with directives: ncp-disable cipher CHACHA20-POLY1305 CHACHA20-POLY1305 on Data Channel is supported by Hummingbird and OpenVPN3-AirVPN library. It is not supported by OpenVPN versions older than 2.5. If your system does support AES-NI, probably your performance will be worse with CHACHA20. Kind regards

@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