Staff

Hello, if the length of the data to decrypt is invalid a possible cause is that curl could not download the mentioned data at all. Usually we see that this problem is caused by a firewall in the customer's system blocking curl, as you all should have already seen clearly from the log. Kind regards

Hello, just for readers' information, you can route specific IP addresses outside the VPN tunnel with Eddie, the Air client software, as well. Kind regards

Thank you. Confirmed and fixed, can you please try again now? Kind regards

Hello! In 2015, full IPv6 support was planned for late 2017. We are confident we will respect this deadline. All important OpenVPN-related issues have been solved, including a major OpenVPN bug which has been fixed internally, by our development team. Most (but not all) of our providers already gave us full IPv6 connectivity. Kind regards

Hello, it looks like a bug, we are going to investigate. Kind regards

Hello, ufw is an iptables frontend. Network Lock does not disable ufw in itself, but definitely modifies your filtering rules by invoking iptables. If you need your custom rules in every situation you should not use Network Lock. Kind regards

Hello! We're sorry, fatal typo. Fixed in 2.13.x Kind regards

Hello, thanks. That was fixed in Eddie 2.12.x. Kind regards

This is a directive aimed to prevent DNS leaks, so it is a Windows-only directive. Anyway superfluous in systems like GNU/Linux where DNS leaks do not exist. @doomced One of the possible solutions for your case is exactly described in the article that you already posted. However, you should not use network-manager-openvpn, because it could break your script to accept DNS push. We would recommend that you either run Eddie or OpenVPN directly. Kind regards

Hello! You need to have them accepted. The fact that the problem is sporadic makes it not relevant: you will not notice any slow down. However, if the amount of dropped packets rises, you will see a dramatic slow down up to a complete halt of the traffic flow to/from the VPN server. At the moment we don't know why LittleSnitch drops a packet only now and then. Kind regards

Thank you very much for the information which will help us clarify the matter. Your settings are just fine. Kind regards

Hello! We could see some time ago that that was a message by LittleSnitch that's somehow misleading. UDP is connectionless so your node can receive UDP packets after it has started talking with an UDP based service, of course (for example: our VPN service). This does not necessarily imply that such UDP packets are an "incoming connection", or an unsolicited "incoming connection". 94.229.74.90 is the entry-IP address of our server Carinae, while port 59573 was likely the ephemeral OpenVPN port (in your local host) . When you enter the VPN in UDP, all of your traffic flow (on your physical network interface) is already/still wrapped in UDP. Kind regards

Hello! After internal, additional tests, we should consider different options pertaining to how Chrome handles Google Safe Browsing. Such options would rule out that your system is compromised. Can you please test from different VPN servers in various locations? Also, if you test from the same VPN server Canis with a different browser (for example Firefox) you should not see any warning page: can you confirm (if not, do NOT proceed)? In any case, we do confirm that no issue is occurring on Canis, of course. Kind regards

Hello, the connection to that web site is hijacked. Notice that the connection is in HTTP, while it must be in HTTPS. Please do not access the web site (VPN or not). From the screenshot we can infer that you were connected to Canis server, which of course does not hijack your connections (just tested integrity and access to that web site from Canis, to be 100% sure). Hijack can occur in various ways. The most common ones, which you should check immediately are: - a hosts file which has been maliciously modified - a poisoned DNS server (make sure to use only VPN DNS when in the VPN) - hijacked DNS queries (make sure to use only VPN DNS, so that your DNS queries can not be hijacked) Kind regards

Hello, please test an "OpenVPN over SSL" connection to port 443. In Eddie menu "AirVPN" > "Preferences" > "Protocols" untick "Automatic" and select "SSL - Port 443 - Alternative entry-IP" (the row will be highlighted in blue). Click "Save" and start a new connection to apply the change. Kind regards

Hello! DNS leaks do not exist in GNU/Linux. About your issue, please have a look at this pinned topic: https://airvpn.org/topic/22715-leaking-dns-with-ubuntu-1704/ Kind regards

Hello, disabling IPv6 might be too problematic in some circumstances, and in general it's an overkill solution. Setting two or three ip6tables rules is a much more practical approach, and of course it is faster, you just need a second. Network Lock feature does that, in case you run Eddie for GNU/Linux. Kind regards

Hello, the micro-routing has been modified accordingly, can you please try again? Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Sweden is available: Norma. The AirVPN client will show automatically the new server, 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 server accepts connections on ports 53, 80, 443, 1194 and 2018 UDP and TCP. Just like every other Air server, Norma supports 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! We had a problem with the update of the eddie.website LetsEncrypt certificate which has been solved just a few hours ago. We apologize for any inconvenience. Kind regards

Hello, that's technically impossible, simply because Eddie never handles and never handled any VPN tunnel, which remains up to OpenVPN. Eddie just creates the exact, identical configuration directives which is also created by the Configuration Generator, and passes them to OpenVPN. Under OpenVPN point of view, until you don't talk to the Management (for example by clicking "Disconnect" button) there is no difference between being run directly by root with a CG ovpn, or by Eddie, provided of course that you order the same directives both in Eddie and in the Configuration Generator. Under Debian, Eddie does not even tell OpenVPN to modify buffers in any pre-determined way, by default. Kind regards

Hello, we use our own DNS servers, not OpenNIC ones. Our DNS servers resolve names in ICANN, OpenNIC and NameCoin name spaces. If an authoritative DNS is slow to respond to our servers, there's not much we can do (we could evaluate some more caching or things like that, but not something really resolutive). Kind regards

We don't pay at all for reviews.

Hello! As you are probably already aware, according to the ongoing renewal of hardware in our infrastructure, the following servers will be withdrawn during June the 30th 2017: In Germany: Aquilae - Menkib - Seginus - Tauri - Velorum - Wezen In Singapore: Aries The aforementioned servers have been already replaced by 6 new servers in two datacenters in Germany: https://airvpn.org/topic/23234-six-new-1-gbits-servers-available-de/ and by 4 new servers in Singapore: https://airvpn.org/topic/23219-four-new-1-gbits-servers-available-sg/ Kind regards and datalove AirVPN Staff

Yes, with a likely change into "AIRVPN DI PAOLO BRINI" in the next versions. Kind regards