Staff

Hello! The ip6tables rules are very simple and we find it strange, or even impossible, that ip6tables is malfunctioning on your system. Can you please send us a screenshot about the presumed DNS leak? We start to suspect that you see the VPN DNS IPv6 address, not the one assigned to your machine by your ISP. Kind regards

Hello! 1) Please make sure to run Eddie 2.12.4 (latest stable release). Old versions might be not fully compatible with openSUSE 13.2 2) Please make sure to enable Network Lock which will block IPv6 packets via ip6tables We are confident to respect the late 2017 planned deadline for full IPv6 support on the vast majority of our VPN servers. Kind regards

Hello! We inform you that we will not be accepting BTC starting from July the 31st, late afternoon UTC, due to the proposed changes and likely implementations in the Bitcoin network. As soon as the transition ends and the network gets "stable", we will re-accept Bitcoin payments. EDIT: we started to accept Bitcoin again since Aug the 1st. Kind regards and datalove AirVPN Staff

Hello! It depends on Google Safe Browsing. YOUR detected IP address (in this case that VPN server exit-IP address) is evaluated by Google which returns a warning considering our VPN server IP address as a source of malicious activity. Chrome does not proceed. Google Safe Browsing listed even Google DNS as a dangerous source of malicious activity and malware before we spread this funny information a couple of weeks ago. We are observed. Kind regards

Hello! Various prepaid cards emitted in the USA can only be used to purchase goods and services in the USA and few other countries. Maybe that's the reason of the issue. Kind regards

Hello! Please follow the "News and announcement" forum. We will keep you updated. And don't worry, only good news will be coming. Kind regards

curl.exe is essential to Eddie. If your system can't run it, you can't use Eddie effectively. Does the same happen with Eddie 2.13.3beta, which includes an updated curl version? Kind regards All exes which come with airvpn do the same thing. (Except Airvpn and Cli) Same thing on the experimental version. Hello! Do you mean that curl, stunnel and plink all crash in your system? Kind regards

Thank you very much for this warning: unfortunately we were never contacted by the authors about this problem, and we are going to investigate in the nearest future. We will keep you posted. Kind regards

curl.exe is essential to Eddie. If your system can't run it, you can't use Eddie effectively. Does the same happen with Eddie 2.13.3beta, which includes an updated curl version? Kind regards

Hello, if you don't run Eddie (our client software), you need to take care yourself of IPv6. IPv6 full support in AirVPN is planned for the end of 2017. If you run Eddie you are protected from IPv6 leaks, except on GNU/Linux. Just enable Network Lock and you are protected against IPv6 leaks in Linux as well. That's all. Kind regards

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