Staff

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

On top of all the good arguments already brought on, we would like to add that in Dallas we have a better protection against © trolls and other entities. Any VPN service operating servers in the United States must take into account the cowardliness of datacenter owners who prefer to just shut lines and services than analyzing claims from copyright industry and other entities. Actually, check our competitors: you will see that even giants like Private Internet Access do not have the guts to allow (just to make an example) p2p protocols in the United States (they re-route outside the USA). Or think of NordVPN which does not allow p2p at all in servers in the USA, in spite of their promises of Net Neutrality, no traffic discrimination, no traffic monitoring etc. They do monitor and discriminate traffic to re-route your p2p traffic outside the USA, or to block it altogether. They re-route or ban an entire class of protocols because through a couple of them copyright infringements might be easier. At the end of the day, please evaluate all the services we provide and all the promises we keep. You will get an explanation about why we focus on carefully picked locations to host our servers instead of basing our business on marketing fluff aimed to gullible people. Kind regards

Hello, it looks very unsafe. The script removes the tunneling routes to the VPN gateway, so your system traffic will not be necessarily tunneled over AirVPN. Comment by grisha explains the problem as well. Kind regards

Hello, problem resolved, can you please try again now? Kind regards

Hello, problem fixed, please try again now. Kind regards

Hello! It's just you. We can access speedtest.net fine from Iskandar. Are you sure your system queries VPN DNS? Kind regards