Staff

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

That's expected and intended. It's not a bug and it is not a different behavior than previous Eddie releases. The logic is that it makes sense to rate a server not from another server (otherwise the general system score would be more accurate), but from your node. Kind regards

Yes, 3 out of 30000 (the amount of accounts connecting in a 72 hours period) is nothing, but we do take care of these cases too. However, in this specific case we have nothing to look into from this thread. Apart from yepper, who has been having a tormented history with intermittent problems for years even when we had in the Netherlands different machines and different datacenters, nobody posted any significant log, not even after multiple recommendations and requests from the community. At the same time, Netherlands servers continue to provide excellent bandwidth and high performance just as usual. At this very moment: 3 NL servers in the top 4 performance, with a significant 215 Mbit/s for a single connection slot of a user (i.e. 430 Mbit/s on the server only for that user). And this is just the common rule with NL servers, you always find them in the Top 10 and providing more than 12000 Mbit/s at all times. Please open a ticket for a proper support and make sure to reply to the support team requests, only in this way you can let us help you effectively. Above all, please do not start with this obsessive fixation that the problem must be necessarily on our side, keep an open mind and try to consider that there's the chance that the problem maybe, just maybe, could be on your side. Kind regards

Hello, just in case: if your ISP only provides IPv6 connectivity, please use ONLY servers Castor and Chara in IPv6, otherwise you just can't use our service reliably (as you don't have IPv4 in such a case). Castor and Chara are the only servers which fully support IPv6, however we plan to deploy IPv6 on most of our infrastructure in a very near future. Kind regards

It might or it might not. It's unrelated. This is more significant and suggests selective traffic shaping enforced by your ISP, local network problems (QoS tools) or other system or line related problems. It's all written in the answers to the FAQ. By the way: In that case you generate a configuration file in which the "remote" directive is filled with a domain name which is updated every 5 minutes (TTL 1 hour) to resolve into the entry-IP address of the best rated server in that country. Each server has a score according to a formula. This is how Eddie computes the score: https://airvpn.org/topic/11208-in-what-order-does-the-client-choose-recommended-servers/ The score to update the DNS record of an aforementioned name is similarly computed, but of course without taking into account the round trip time between your node and the server. Kind regards

Hello, Netherlands servers are connected to AMS-IX with enough redundancy, that's why several of them enter so often (if not always) the top 10 Users speed. You should first check for bottlenecks in your local network, congestion in your ISP network (especially since you experience intermittent problem), bad peering. Kind regards

Hi, in 2016 and 2017 Japan drafted a new legislation which went into full force at the end of May 2017 on privacy and data protection. The new framework has been recognized as offering a high level of safeguards for citizens, comparable to those offered by the EU legal framework. As such, Japan has been added into the EU white list of countries offering an adequate level of personal data protection (the recognition has been mutual, since Japan created a similar white list, in which the EU has been added). Last but not least we have found a datacenter which meets our requirements. Kind regards

Your iptables version does not support --wait, consider to upgrade to Eddie 2.14.2beta which does not use this option anymore with iptables. Since DNS leaks do not exist in Linux, the thread subject is misleading and the problem could lie somewhere else. Last but not least, it is odd that a DNS test shows your public residential IP address, are you running a DNS server in your local network? Kind regards

Hello, it's expected when flood comes from our own VPN servers themselves. Kind regards

. 2018.03.01 13:50:52 - OpenVPN > /sbin/ip link set dev tun0 up mtu 1500 . 2018.03.01 13:50:52 - OpenVPN > MANAGEMENT: Client disconnected . 2018.03.01 13:50:52 - OpenVPN > Linux ip link set failed: could not execute external program Before anything else please make sure that "ip" is in /sbin and that it can be accessed. Kind regards

It may happen when an attack against our web site starts from our infrastructure (the enemy within ). Forgive us for the typos in the warning message. Kind regards