Staff

Hello! block-outside-dns is a Windows-only directive (rightly so, since Windows is the only system with endemic DNS leaks caused by incomplete DNS implementation) and is fully effective to prevent DNS leaks. Please check the OpenVPN manual here: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage Warning, this directive is unsupported in OpenVPN versions older than 2.3. Windows DNS leaks, anyway, have always been prevented in the Air client software "Eddie". If you run Eddie in Windows, adding this directive is superfluous. Kind regards

Hello! Check the directive: reneg-sec n where n is in seconds in the OpenVPN manual: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage OpenVPN uses the previous key as long as the new key is not fully re-negotiated. Such "smart overlapping time window" ensures no communications break. Just make sure to not set extremely low values, because a re-keying adds anyway a moderate overhead in bytes, in computation power and you probably don't want that your side is willing to ask for a re-keying immediately after the previous one is over. Kind regards

Hello! No manual addition of any directive is necessary. Kind regards

Eddie is free and open source software released under GPLv3. At the moment we release under GPLv3 only the stable versions of Eddie. The various experimental versions (internal alpha, internal beta, public beta) are not released under GPLv3 and you should avoid them if you don't feel adventurous. Just stick to what you find on GitHub and do not take into consideration experimental / beta versions. This is not immutable and can change in the near future. Kind regards

Hello! Please make sure that no QoS / packet filtering tools, both on your router and system, interfere with traffic, and also test (with the connection mode that could provide you with the highest throughput) different servers in various locations around you (prefer servers with lowest round trip time). We don't see any bad packet / packet error in the log entries, so we tend to rule out MTU size problems. Some users reported in the past interesting performance boost (in Windows) after having fine tuned the TCP/IP stack with TCPOptimizer. If all else fails, you could give it a try, please see here: https://airvpn.org/topic/24126-tcp-optimizer-for-windows It looks like that with some TCP/IP stack optimization Windows can partially fill the gap with the other systems in the tun/tap interface "performance". It is not easy in Windows to match the throughput you get in the tun/tap interface when compared to other systems (you don't have fast-io, you don't have any native tun/tap support and some other problems due to bad architecture), but with TCP Optimizer and the latest tun/tap driver throughput can be improved (of course, it is assumed that your system has a powerful enough CPU). 120 Mbit/s is not bad anyway if you make a comparison with just 5-6 years ago, when beating 100 Mbit/s on the tun/tap interface with the old tun/tap driver in Windows was deemed as impossible. Kind regards

Hello, please post Eddie system report ("Logs" > life belt icon > copy all > paste), it will tell us your Operating System exact version and many other settings that might help in tuning. Kind regards

Hello, the log is fine but shows that you don't take care of DNS push, Under GNU/Linux OpenVPN does not handle the DNS push from the server, so an option to consider is that your system queries DNS servers that are inaccessible from the VPN (typically ISP DNS which accept queries only from inside the ISP network). Please check your /etc/resolv.conf file. Also consider that you can run Eddie, the free and open source Air software: it will take care of the DNS push. Without Eddie, some methods to accept the DNS push under GNU/Linux are described here: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf Kind regards

This makes no sense (or worse, it makes a sinister sense ), but maybe you have just talked with someone who did not even know what you were talking about. Please note that this is not the forum to talk about competitors, not even when doing so exposes our competitors flaws. This is the correct forum to continue with comparison etc.: https://airvpn.org/forum/39-other-vpn-competitors-or-features/ Kind regards

Hello! Yes, of course. Since its birth, AirVPN always configured OpenVPN to work in TLS mode with PFS. And there's more: AirVPN uses 4096 bit DH keys and unique DH keys on each VPN server. Kind regards

@VectorXYZ Hello and thank you very much for the information. It would be nice to know why this ISP likes to block IP addresses of VPNs, although we can imagine why. Entry-IP 3 and 4 will be added to most (if not all) servers soon, probably during April. The deployment is ongoing (almost over now) and we think to activate all of them simultaneously with IPv6 support. Kind regards

No, it's not equivalent. In most OpenVPN versions. omitting "comp-lzo no" when comp-lzo is specified (even when excluded) on server side will cause connection failure. This is an OpenVPN questionable implementation but that's the way it is. We confirm anyway that we will keep into account all the problems raised in this thread to maximize retro-compatibility whenever possible. Kind regards

Hello! OpenVPN over SSL works just fine and you don't need anything else. However, we're also interested in trying to bypass some blocks in UDP, where UDP is not blocked globally, or in TCP without the aid of an additional TLS tunnel. For such purpose tls-crypt might help. It is now available in Chara and Castor, and will be deployed onto most or all servers in a month or so. We would be glad to receive feedbacks (not here, only in private tickets) from China or Iran. Please run Eddie 2.14 to support the new feature or re-generate properly the configuration files to test. UPDATE: tls-crypt is now available on all servers, please see next messages in this thread. Kind regards

Hello! Closing Eddie before shutting down the system is any case the best option to make sure that Eddie has enough time to restore the system settings. That said, you can just un-tick "Exit confirmation prompt" in "AirVPN" > "Preferences" > "General" to let Windows shut down even when you don't close Eddie first. Kind regards

Can you please keep in mind that "its" has NOTHING to do with "it's"? Fixing the topic subject.

Hello! It has been fixed, thanks. Sorry about that. Kind regards

Hello! We're very glad to inform you that three new 1 Gbit/s servers located in Norway are available: Camelopardalis, Cepheus and Gemini. The AirVPN client will show automatically the new servers, while if you use the OpenVPN client you can generate all the files to access them through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The servers accept connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other Air server, they support OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! The tun/tap interface does not come up. In several cases the excellent recommendations by LZ1 will fix the problem. In some other cases, some additional steps are necessary, please see below. If the problem persists after you have disabled any third-party antivirus and firewall, and you have also ascertained that the tun/tap interface is "Enabled", please try to set the tun/tap interface to "Always connected": Go into device managerFind your TUN/TAP AdapterRight click on itSelect "Properties"Select "Advanced Media Status"Set it to "Always Connected"Click "Ok"Reboot the computer.After the system has restarted, please insert the following directives in Eddie window "AirVPN" > "Preferences" > "OVPN Directives", "Custom directives" box: route-method exe route-delay 5 120 and test again. Kind regards

Hello! To get one of the most minimalistic interfaces you can run Eddie in command line mode or OpenVPN directly under screen. Such a setup does not even require any graphical environment. About screen utility: https://www.gnu.org/software/screen/ Kind regards

Hello! Currently there's no such option but it might be taken into consideration for Eddie 3. Kind regards

@zhang888 Well, there is a special case for which you really want that the DNS server address matches the VPN gateway address (as it happens in Air if the client accepts the DNS push), i.e. when you are in an untrusted network. It's the most secure method to prevent DNS hijacking, an exploit which is possible only when the mentioned addresses do not match. We probably should have emphasized this aspect because of this almost-exclusive feature of AirVPN, unfortunately the question was messed up as you noticed. Kind regards

The ping times are not updated from your node while the system is connected to the VPN, but other data are downloaded (very useful when you can't update such data while not connected to the VPN, for blocks etc.). Once you update manually, the old ping times are no more displayed. Currently only stable versions source code is available. This is not immutable but it has been a habit so far for practical reasons. Kind regards

Hello! That's correct, we still use comp-lzo and we will keep using it for some time. Change with "compress" will be done in due time or not at all. Compression is disabled on all servers, so in the current configuration it makes no difference, but the future incompatibility is kept under consideration, of course. In the near future we might be testing again compression or maybe we will keep it completely off in order to have compatibility with the whole OpenVPN 2 branch (because "compress" is not supported in OpenVPN 2.3.x or older, while "comp-lzo" might be dropped in OpenVPN 2.5 and higher). No definitive decision has been taken. Kind regards

Noted. Something will be modified to solve the issue in the next releases. Kind regards

Hello, it is not possible to have WebRTC (or any other application binding to the physical network interface) working with Network Lock enabled, unless you modify the firewall rules after you have enabled Network Lock. Maybe you might be confusing the matter with the HTML5 geo-location (if so, just disable HTML5 geo-location feature in your browser). HTML5 geo-location is not a leak out of the tunnel, since your browser sends out your location to the final service in the http stream inside the tunnel. It's a problem in your system, completely out of the scope of our service (and rightly so, because our service will never inspect your packets, even if that was possible in absence of end-to-end encryption). Kind regards

The ticket is correctly resolved, it has been ascertained that the problem is in your ISP or system. Unfortunately, as you surely understand, the support team can do nothing more about it. At least we could make sure that the problem is not on our side. Kind regards