Staff

We already mentioned that we are very much interested in the project. Of course selling some service now based on Wireguard would be culpable negligence, it is in testing phase and is incomplete. From the home page of the web site project: When the developers will decide the final protocol and Wireguard is released as a stable version things will change and a peer review etc. will become possible. Kind regards

It's quite good, it always receives, month after month, the first, second or third best feedback between all of our providers (feedback from AirVPN users we mean). Kind regards

Hello! Yes, that's correct and intended. If an older version of Eddie showed latencies after a refresh while the system is connected to some VPN server, that was not an accurate behavior, because Eddie should show round trip times from your node to VPN servers, not from some VPN server to other VPN servers: that's not a useful info (to pick a server) and is anyway visible in the ping matrix of the real time servers monitor. monstrocity suggestion should not be a workaround: simply, Eddie will not print the round trip times while the system is connected to the VPN and you will see the older ones. If you force an update with the button, then you should see the round trip time and the stars disappear. Kind regards

when i open the "xxx.ovpn" file with a text editor and change the line "proto udp6" (this is the line before "tls-auth 'ta.key' 1") to "proto udp", i can import without the error message however the connection is not working afterwards. do you have any ideas what i could do different? should i set up the connection manually? thanks in advance! Hello! It seems a nm-openvpn plugin parser bug: when it finds "udp6" it assumes that it is dealing with some certificate or key, instead of an ovpn configuration file. nm-openvpn plugin has historically been affected by so many critical bugs that we renounced to support it years ago. Still nowadays we would recommend that you get rid of it. Run OpenVPN directly and this problem should be sorted out. Important: you also need OpenVPN 2.4 or higher version for tls-crypt support. IPv6 support is also problematic in OpenVPN versions older than 2.4. Kind regards

Hello! IPlease make sure that the listening service is really running and listening to the correct port, and that no firewall blocks packets to/from the service while the system si connected to the VPN. Note: we assumed that the listening service runs in the same machine that connects to the VPN: if that's not the case an additional step is required, you need to forward packets from the tun interface of the connected device to the final machine running the service. Kind regards

And yet another replacement from other ASNs to M24/7 / AS9009. If this trends keep to continue, i will probably not renew my account. Regards Hello! You have already discussed about this months ago and then we replied that approximately 23% of our servers in Europe are in M247 datacenters. This percentage remains unaltered and goes down to 10% when you consider the global Air infrastructure. Such percentages are well inside the redundancy margin we keep for bandwidth, availability etc.,, so there's no reason to worry. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in New York City (NY, USA) is available: Lich. The AirVPN client will show automatically this new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Lich supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/lich Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! We're very glad to inform you that two new 1 Gbit/s servers located in Zurich (Switzerland) are available: Dorado and Sextans. The AirVPN client will show automatically the new servers, while if you use the OpenVPN client you can generate all the files to access it 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 "second generation" Air server, Dorado and Sextans support OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Dorado and Sextans replace Kitalpha which will be dismissed within Nov 17th, 2018. EDIT: by popular acclaim good old Kitalpha will NOT be canceled. You can check the servers status as usual in our real time servers monitor: https://airvpn.org/servers/dorado https://airvpn.org/servers/sextans Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! Please enable "Log debug" in "Preferences" > "Logging". It will increase log verbosity which could provide some clue about what happens (feel also free to send the log or even better a system report, even in a ticket). EDIT: also, while Eddie is not running, you might rename the file ~/.airvpn/default.xml (root access is needed to do that). It's Eddie configuration file. At the next run Eddie will create a new default.xml file with all default settings: check whether the problem gets sorted out or not. Kind regards

Hello! Please see here: . 2018.10.23 13:12:26 - Cannot retrieve systems & servers data. (curl: (7) Failed to connect to 127.0.0.1 port 9151: Connection refused - with 'socks' (always) proxy and 'none' auth) and here: 2018.10.23 13:12:42 - OpenVPN > Attempting to establish TCP connection with [AF_INET]127.0.0.1:9151 [nonblock] You have configured Eddie to connect over some proxy running in your system but your proxy is either not running or not listening to localhost port 9151. Please check your proxy settings. If you did not mean to have Eddie and OpenVPN connect to some proxy, check the settings you have modified in "Preferences" > "Proxy/Tor". Kind regards

Hello! We can't reproduce this issue. For further investigation please open a ticket. Kind regards

Hello! Yes, this is planned in a very near future. Kind regards

Hello! Thank you very much for the report, a bug fix is needed. The issue occurs only on Android 6 and has been confirmed. Kind regards

There is no problem on our end. The misconfiguration of imdb.com DNS has been confirmed twice by two different specialized services. Of course this is a different problem than the blocking one (when our servers are blocked by imdb web server and/or imdb authoritative DNS) but both of such problems are on imdb side. On our side we can only intervene with tricks to bypass blocks of the mentioned second scenario. Also it is not true that you can connect merrily to imdb.com without AirVPN. We detect the identical problems from Italian ISPs (using ISP DNS) residential lines. Kind regards

I noticed the same thing. Only one Vancouver server now. What happened? Hello! Getting rid of datacenters/providers that can keep their promises only for a few weeks. It looks like we did not get a good service in the Vancouver area in the last 8 weeks or even more (confirmed by users feedback) so radical changes have been mandatory. We will expand infrastructure in Vancouver with the Pisces ISP in two weeks if there are no issues (at the moment Pisces meets our requirements). Kind regards

Hello! Multiple blocks are enforced: and a general UDP and/or OpenVPN block. Even if the authorization check fails Eddie can go on by using the latest available info retrieved from your HDD. Such info will be updated once inside the VPN, when all the blocks are ineffective. Please try the following settings: from Eddie main window select "Protocols" > "Preferences"untick "Automatic"select the line with entry-IP address 3, protocol TCP, port 443 (the line will be highlighted in blue)click "Save"test connections to various servers in various locationsKind regards

Hello! The imdb.com misconfiguration is explained in the thread mentioned by psychlops: https://airvpn.org/topic/29835-problems-with-imdb-dns https://dd.us.imdb.com (which is also imdb.com CNAME record) seems correctly configured so you can point to it if the problem on their side goes on. Kind regards

Hello, if the fact (losing the servers score displayed by the stars) occurs when the system is connected to the VPN that's expected and intended for obvious reasons. Kind regards

Hello! The problems showed by MXToolBox are confirmed by https://www.dnsqueries.com/en/domain_check.php (we don't know why you mentioned our servers since the problem you correctly point out is in imdb.com). Note in particular, in the WWW section of dnsqueries.com check page, this: Kind regards

Hello! Two distinct problems probably. The second one would be a block of some IP addresses of our VPN servers (check the "Route check" page and see). We will look into the issue. Kind regards

Hello! Maybe you try to access Netflix from a device which is behind the Raspberry box. In this case please check the DNS settings of such device, which of course take precedence over the Raspberry DNS. Kind regards

Hello! If you run OpenVPN directly you should consider some script to take care of the DNS push (OpenVPN will not process the DNS push by itself). Please check here: https://wiki.archlinux.org/index.php/OpenVPN#Update_resolv-conf_script Kind regards

Hello! This is unexpected and deserves an investigation, thank you for the head up. EDIT: we're sorry, the account does not have any forwarded port and/or any linked name for our DDNS. Maybe you use different accounts. Please open a ticket to clarify and let us check the issue. Kind regards

Please do not hijack threads, this has nothing to do with the OP problem. Exit-IP addresses of VPN servers are shared, this feature is intended and a key to enhance the anonymity layer. Kind regards

Hello! Can you please test Eddie 2.17.2beta? This issue (Network Lock takes several minutes to be applied because each iptables call takes a long time, like 300 ms) appears resolved: https://airvpn.org/topic/29570-eddie-217beta-released Kind regards