Staff

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.13beta. It is ready for public beta testing. To download Eddie 2.13beta please select "Other versions" > "Experimental" from the download page. Update 24-Jun-17: version 2.13.2beta has been released. Update 22-Jul-17: version 2.13.3beta has been released Update 18-Aug-17: version 2.13.4beta has been released Update 19-Aug-17: version 2.13.5beta has been released Update 24-Sep-17: version 2.13.6beta has been released Update 02-Oct-17: version 2.13.6 has been promoted to "Stable" This version features several bug fixes and updated software in the package (OpenVPN 2.4.3 for example). Windows edition lowers the tun interface metric to patch the problematic DNS implementation in Windows 10 "Creator". Please see the changelog: https://eddie.website/changelog/?software=client&format=html Do not hesitate to write in this thread if you decide to test Eddie 2.13beta and you find some glitch or bug. Kind regards & datalove Air Staff

Hello, that was a bug affecting 2.10.3 and 2.11.x, but it has been fixed in 2.12.4. Can you please describe exactly the IP addresses combination/setup that causes the issue? A system report generated by Eddie will let us see the exact Eddie configuration and could provide precious clues. Click "Logs" tab, click the life belt icon and paste into your message. Kind regards

Problem solved: customer did not allow Eddie to run with root privileges.

Database error, as already explained. In ipleak.net we query MaxMind and other databases. All of them are in general inaccurate. You're wrong. The servers reported in Atlanta are in Atlanta. Refer to the real time servers monitor to know the location of each server. ping is not very relevant because you wrongly assume that geographical proximity is equivalent to network and/or ICMP proximity. Verify with traceroute that the servers are in Atlanta. Kind regards

Hello! Of course if you have a malware which modifies without your knowledge the firewall rules, then anything is possible, even much worse things. Our service will NOT protect compromised systems in any way. Also please do not forget that our service purpose is NOT protection of your system against malware. Kind regards

Hello, connect to your router via telnet or ssh and issue command "ifconfig". Kind regards

Hello, 10.4.0.1 is always accessible regardless the port you connect to and the protocol you connect with. It is the only always reachable address and it is the main address of any DNS server of each VPN server. Each subnet is a /16 so your reference to "249 servers IP" makes no sense (we underline just in case this is bringing confusion). However, it is recommended (and this will happen by default if you run Eddie or anyway accept the DNS push from the server) to use the same IP address for the VPN gateway and the VPN DNS server. Having these addresses match prevents an attack based on DNS hijacking described in some research papers. So, if you connect to port 80 with protocol UDP, we would recommend to set the DNS server address to 10.8.0.1 (even if 10.4.0.1 would work anyway) because the VPN gateway would be 10.8.0.1. Also please see https://airvpn.org/specs to know exactly which subnet you will enter. This knowledge is not strictly necessary: if you accept DNS push, you will always have VPN gateway and DNS addresses match. Kind regards

Hello! If the notice is not a hoax, then your traffic was not tunneled. Enable Network Lock to prevent any possible leak, including leaks caused by unexpected VPN disconnections and leaks caused by the torrent client itself when it is misconfigured (example: UPnP enabled, or any other option causing the software to bind to the physical network interface). https://airvpn.org/topic/9170-do-you-allow-p2p-how-can-i-optimize-performance-of-emule-and-bittorrent-with-airvpn/ https://airvpn.org/topic/12175-network-lock/ Kind regards

Hello! A probable reason for the warning you get is that you have the same gateway for two different network interfaces. In such cases some OpenVPN versions will abort the connection phase. According to your description and to the fact that you have Network Lock enabled, we have no reasons to suspect that you can have any traffic leak outside the tunnel anyway. If you don't need two network interfaces with the same default gateway (in most cases there is no reason for that), the quickest way to get rid of the warning is just disabling the one that you don't need. For example, if you connect to your router via Ethernet, you can disable the WiFi card. Enjoy AirVPN! Kind regards

Hello! Today we're starting AirVPN seventh birthday celebrations! From a two servers service located in one single tiny country providing a handful of Mbit/s, the baby has grown up to a wide infrastructure in 18 countries in three continents, providing now 197000 Mbit/s to tens of thousands people around the world. 2017 is an important year, not only because not all VPN services have flourished or even survived for seven years, but also because 2017 is the year we planned to enhance the growing child with full IPv6 support as well as tls-crypt obfuscation. Software related development will be powered up, with some very exciting news you will get in the next months. If you're curious to know something about a series of fortunate events which gave birth to AirVPN, have a look here: https://airvpn.org/aboutus To worthily celebrate Air's seventh birthday, we're glad to inform you that starting from now we will offer a 25% discount on all plans. Hurry up, celebrations as well as this special offer will end on June the 6th, 23:59:59 UTC! Kind regards and datalove AirVPN Staff

Hello! Yes, the attacks you talk about, usually based on timing attacks in low latency networks, are not meant to be prevented by separate entry and exit-IP addresses. The correlation attacks which are prevented by separate entry and exit-IP addresses are different. When two nodes of a same VPN connect to each other via a public address which is also the VPN gateway public address they will start exchanging data in clear text outside the tunnel (this is quite obvious, check your routing table to understand exactly why). When that IP address is shared between the nodes connected to the VPN server, this opens up the way to a wide variety of correlation attacks to discover the real IP addresses of the nodes connected to a VPN server. The adversary does not need to control or wiretap all the relevant network segments, it just needs to enter the VPN as a normal user, forward ports remotely and study the proper way to start the attack on the target or targets (the attacker will need to convince the target or targets to connect to any of the services he/she controls behind the VPN). This is not an OpenVPN (or other VPN software) vulnerability, it's just how routing works. Incredibly, even nowadays you can find VPN services around the world which do not take care of all the above and, even more incredibly, famous "VPN reviews" sites do not even talk about this issue. Kind regards

Hello! In 2015, full IPv6 support was planned for late 2017. We are confident we will respect this deadline, even though we have met unexpected OpenVPN bugs in handling IPv6 which have been and are slowing down the whole process remarkably. Kind regards

Hello! Network Lock is a set of pf rules so if Eddie crashes Network Lock will remain active. Kind regards

We wouldn't, why do you say so? Kind regards

Hello! Disable any filter against UDP in the router packet inspection/filtering/QoS/whatever tool and keep your router firmware up to date. Note that we also support TCP but it would be a pity that you renounce to UDP, which is more efficient, for the requirements of a machine. Under a more philosophical point of view, you should put yourself in a position for which machines do what you want, not the other way around. Kind regards

Hello! You don't need to log anything about the traffic content, type, source or destination to know how many simultaneous connections an account has established. You only need a counter for each account. Kind regards

Hello, it's a wrong detection. When you connect to our VPN servers all of your traffic is wrapped in UDP by default. You can change protocol but UDP is the most efficient one due to how OpenVPN works. Kind regards

This scenario resembles an attempted packet injection by some MITM analyzing traffic outside the VPN server (when it is not encrypted by OpenVPN). Again what you describe is impossible. OpenVPN has a packet authentication system which would have rejected the forged, injected packet. The most plausible explanation, if Network Lock was really enabled and firewall rules were not modified, is that it never happened and you misinterpreted something. If we discard this last explanation then the fact that your system is compromised must be taken into serious consideration. Kind regards

Hello! Sorry, but that's simply not true. Also note that ping (ICMP) is not even at the transport layer (it's at the Internet layer). And please do not confuse incoming packets reaching one of your system ephemeral inbound ports as a consequence of an already opened socket etc., with incoming connections to a listening service (if any). Anyway you can have TCP incoming connections with remote port forwarding (you can also have UDP packets forwarded, so the system is not limited to incoming connections over TCP). By default, an Air VPN client has no forwarded ports, so it can not receive any incoming connection, and it can not receive forwarded UDP packets. It's physically impossible, if you have not forwarded remotely any port. You can remap any remotely forwarded port to any local port. If you receive unsolicited packets from the Internet and you have not forwarded any port in your account panel, such packets have reached your ISP-assigned IP address and have nothing to do with the VPN server. Do not forward ports in your router or keep Network Lock enabled to prevent that. Kind regards

Hello! We are working to provide full IPv6 support and IPv6 is already configured in various VPN servers, so in ipleak.net DNS fields you will see both VPN DNS server IPv4 and IPv6 addresses. Kind regards

Hello! It can't come from the VPN server because incoming packets are not forwarded to clients, except those directed to the remotely forwarded port (to the proper client VPN IP address). By default no inbound port is forwarded to a client. Kind regards

That's a normal DNS query respecting the system settings. It has nothing to do with DNS leaks. A DNS leak is a totally different thing which affects only Windows (which does not have a DNS implementation, lacking the concept of global DNS). Kind regards

Hello! AirVPN is the 4th OSTIF top donor: https://ostif.org/top-ostif-donors/ We contributed specifically for the OpenVPN audit. We're glad to see that the audit completed quickly and that no serious security vulnerabilities have been found client-side. Even server-side, the only two security issues are not particularly worrying. A denial of service can be triggered by a client sending at least 196 GB in a certain way, while another denial of service can be caused by having the tls-auth key. Let's remember anyway that the bug bounty remains open. Our upgrade schedules sever-side remain unchanged, as well as Air client software release cycle. Each new release of our software is packaged with the latest OpenVPN version and keep in mind that you can configure the software to use any OpenVPN version you prefer. Kind regards

Hello! This is impossible. There are no DNS leaks on GNU/Linux. The error message seems quite explicative, you don't have the permission necessary to save the file. Please make sure to edit the file with root privileges. Kind regards

No. See also https://curia.europa.eu/jcms/upload/docs/application/pdf/2016-12/cp160145en.pdf for any doubt. No, it's false. It's not the first time that this "reviewer" posts false and potentially defamatory claims against AirVPN, and probably not in good faith as shown in the following post: https://airvpn.org/topic/19586-a-review-on-another-site/?do=findComment&comment=48971 As you can see, the "reviewer" does not hesitate to perform low level tricks (replacing a lie with another lie, stating that a fact is "an opinion of his") when he's nailed down to his lies with incontrovertible facts. The site also includes tons of mistakes about AirVPN, all of them damaging us, stating lower features than those that we really provide. Just to make a few examples, in the table it says that e-mail address is required (false), that we have 138 VPN servers (meaning that the web site has not been updated for a very long time, because we offer 205 servers currently) and some other "horrors" which hint to a bad combination of technical incompetence and lack of good faith. They are all dedicated servers with dedicated ports and IPMI etc. access restricted to VPN or a specific, limited pool of addresses. Kind regards