Staff

Hello! Try to reset both adapters (or uninstall one of them) and make sure that no OpenVPN instance (or any other program which might be locking the tun/tap interface) is running when you then launch Eddie. Select "Start" > "Control Panel" > "Network and Internet" > "Network and Sharing Center" > "Change adapter settings". Right click on the tun/tap Windows adapter and select "Disable" from the contextual menu. Right click on it again and select "Enable" Kind regards

Hello! From your description you might need the traffic of those applications OUTSIDE the VPN tunnel, so you should black list, and not white list, them. If you choose to filter according to a white list, applications in the white list will be the only ones whose traffic is tunneled.If you choose to filter according to a black list, all applications will have their traffic tunneled except those ones which are included in the black list. Kind regards

hi guys! any news? Hello! Yes, we are very glad to inform you that we are deploying this new feature on the Configuration Generator with the addition of new FQDNs. Probably everything will be available today (Nov the 7th 2018) or tomorrow for everybody. Kind regards

Hello! Absolutely. This feature will be implemented. Kind regards

@cm0s We added XMPP as a courtesy and everybody can use it from any account registered on the web site. It's not even required to use XMPP with an account "with the customer's billing information". We don't put at risk anyone with XMPP. If you don't like an additional service provided for free to everybody (and NOT restricted to AirVPN paying customers, we underline it once again) just don't use it, where's the problem? Kind regards

Hello! Please try different buffers for the OpenVPN sockets. In your case you might try to shrink them. You can change buffer sizes in Eddie window "Preferences" > "Networking". Try 128 KB and even 64 KB buffers. Such sizes are too small to get high performance but in some cases may help in online gaming, where you are more interested in response times than pure broadband alone. Kind regards

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