Staff

Hello, the problem seems to be intermittently even worse: as you can see you often get SERVFAIL, i.e. a failure of the authoritative DNS servers. Normally a SERVFAIL means that the authoritative DNS server is down or refuses connections from our DNS servers, we will investigate. Kind regards

Hello! Xfinity enforces traffic shaping, please check their policy. Normally OpenVPN with UDP is shaped most of the time for all broadband users, according to dozens of reports we have. According to several customers of ours, the best throughput is obtained via tls-crypt connection in TCP to port 443 (in AirVPN, you get this connection mode to VPN servers entry-IP address 3 - OpenVPN 2.4 or higher version is required). This connection mode has the ability to circumvent any specific shaping against OpenVPN and UDP, so you will remain subjected only to the general limitations and traffic shaping policies (and of course congestion, if any) enforced by Xfinity. Kind regards

Hello! Yes, this is planned in a very near future. In the meantime you can download the apk from our own repository, check the first message of this thread. Kind regards

Hello! Can you please test Eddie 2.17.2beta and check whether the problem is resolved or not? Please see here to download Eddie latest beta release: https://airvpn.org/topic/29570-eddie-217beta-released Kind regards

The load balancing is internal to each server, yes, and it is rigorous. The global load balancing on VPN servers is quite different. It is a best effort balancing based on servers scoring and Eddie decisions for those users who let Eddie pick a server automatically and those who use a different client with Air country or continent domain names. The global load balancing can not be rigorous because each customer is free to force a connection to any server regardless of that server load (with some upper limit though which is rarely reached anyway). Kind regards

Hello! By popular acclaim Kitalpha will not be canceled. Our previous decision was a consequence of the fact that Kitalpha has old hardware, no AES-NI supporting CPU and no IPv6 support. Since the datacenter could not offer IPv6 support, we decided to switch to a less obsolete infrastructure. While nothing can be done for IPv6 support, it is possible that we can replace the server at least with an AES-NI supporting CPU (unavailable until some time ago, but now things might have changed), so that Kitalpha will be always in the same datacenter, but with a more modern hardware. If no AES-NI CPU is available, we will anyway keep Kitalpha as it is now. The advanced load balancing system works well and mitigates the bottlenecks caused by non-AES-NI supporting CPUs. Kind regards

Hello! This issue should not occur with latest Eddie stable release (2.16.3) and with Eddie 2.17.2beta. Can you tell us which Eddie version you're running (check in the "About" window)? Can you confirm that the problem occurs even when you shut down Eddie properly (with the "Exit" menu item, for example)? Kind regards

Hello! Yes, right. What Eddie version are you running in which Operating System? No firewall interfering? Same "Bad access" error message toward any and each IPv6 supporting VPN server? Kind regards Kind regards

Hello! Can you please send us Eddie log taken just after one of those errors occurred? What is the Android version of your FireTV? Kind regards

Hello! We prefer a safer approach. Testing the implementation of a stable protocol has nothing to do with testing an experimental protocol. IPv6 is definitely not an experimental protocol since so many years: the test is on our servers settings, not on the protocol, which is stable. Completely different thing is testing a protocol which is itself experimental. This is anecdotal and unfortunately has no value at all. Side note: IPv6 configuration completed the beta phase successfully, the disclaimer must be deleted. Kind regards

Hello! Please download the configuration file either with Chrome or Safari browser. A bug in Firefox will cause the download of a part of HTML page instead of the real file. Kind regards

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