Staff

Hello! Can you please try to disconnect your account, re-connect it and report back? On the server where that was possible, it was immediately fixed. Please verify again. Kind regards

Hello! The problem has been fixed, can you please test again? Kind regards

Hello! It means exactly that: your service is reachable through your real IP address. It's dangerous because it opens the way to correlation attacks. Please make sure to not forward ports in your router. Network Lock will also solve the problem. Kind regards

@DarkSpace-Harbinger It is not a reliable method at ISP level, too easy to bypass. But of course simpler methods are much more effective. Kind regards

Hello! We're glad to inform you that the problem has been solved. Kind regards

Hello! We're glad to inform you that the problem has been solved. Kind regards

Hello and thank you for your patience! We are working to solve the problem as soon as possible. In the meantime, please simply disable the DNS check from inside Eddie. Select "AirVPN" > "Preferences" > "DNS" and untick "Check Air VPN DNS". Click "Save" and start a new connection. That's all. DNS check is a redundant option so you can keep it disabled safely while we work to fix the issue. Side note: you are running an archaic Eddie version (2.11.15). Latest stable version is 2.13.6, you might like to upgrade. Kind regards

Hello and thank you for your patience! We are working to solve the problem as soon as possible. In the meantime, please simply disable the DNS check from inside Eddie. Select "AirVPN" > "Preferences" > "DNS" and untick "Check Air VPN DNS". Click "Save" and start a new connection. That's all. DNS check is a redundant option so you can keep it disabled safely while we work to fix the issue. Kind regards

Hello and thank you for the head up! The communications between the nodes inside the VPN have always meant to be blocked. Nodes can communicate inside the VPN only with common services, such as DNS server for example, since Air birth. We have found a flaw in the recent updated configuration and we have fixed it, can you please test again now? Should you find any further issue, please specify also which server(s) you experience the problem on. Kind regards

Hello! Yes, but it's not recommended. "europe2.vpn.airdns.org" for example is resolved to the highest rated server at the moment of the generation, if you force resolution you will always connect to the same server. As explained in the tooltip, that's useful in case of DNS poisoning (China for example). Previous versions of Config Generator had an option to dump all servers with many "remote" directives, to allow OpenVPN to pick (randomly) a server, but the option was disabled because OpenVPN doesn't accept more than 64 "remote" directives. if necessary, you might anyway emulate that option by editing the file with a text editor (with "remote-random" and then a maximum of 64 " remote" directives, see also https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses for this purpose). Anyway, europe2.all.vpn.airdns.org contain all IP servers of the picked region, as explained here: https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses Kind regards

Thanks. That's helpful. I can determine the IP addresses from that. Shouldn't resolve hosts put the actual IP address in the configuration file? Hello! Yes, thanks for the head up, this is a critical bug, it will be fixed. The CG also generates invalid names when you select entry-IP 2, exactly as you reported. Going to investigate and fix. Kind regards

Hello! The names you entered do not exist. Please replace them with: america2.vpn.airdns.org asia2.vpn.airdns.org europe2.vpn.airdns.org Kind regards

Hi there! I have a FTTH 1 Gbps, without AirVPN I get 945 Mbps (that is 115+ MB/s). With Airvpn turned on it is 100 - 150 Mbps (that is max 15 MB/s). No limitation on my hardware. I think that Airvpn HAS a an uplimit. Or not? Hello! Is your system Windows? We have had some reports according to which some Windows systems can't beat 130-140 Mbit/s with the current tun/tap driver. We can't confirm or deny, but it deserves more data collection. Kind regards

Hello! All the routing servers are used and the graphs are displayed correctly, as far as we can see. About AU2, it's used, but not much. In the last year the peak bandwidth was 8 Mbit/s only! Kind regards

Hello! Note that the fact that Canada is black listed is irrelevant in your case, because according to your description you have defined lists for the servers. Try this: - delete any list both on servers and countries - white list United States - test again If the problem persists with the above list (i.e. Eddie connects to a Canada server) please send us a system report. Kind regards

Hello, this a logic flaw or a typo. Probably you meant "on the opposite of what the writer of the rebutted article meant", i.e. the writer claims that it's mandatory to build a business model based on false, lying "no traffic logging / inspection" policy in consideration of our prices, while the rebuttal shows how the legal framework and the working infrastructure of AirVPN prove the contrary after more than seven years of operations. The rebuttal also explains why lying on the no logging and no inspection policy would be catastrophic under a purely business view. This is obvious, and actually the rebuttal has been written with the account of AirVPN Staff, so there is total transparency and no ambiguity. It's not that the rebuttal has been written in the name of someone who pretends to be outside AirVPN or anyway super-partes in disguise. Luckily the fact that we fight for freedom of expression does not prevent us to exercise such fundamental right whenever we wish so. In reality we do. In a VPN where all clients are known and trusted, a client might like to share its devices with any other client, but this is a special case which does not happen normally, not even in corporate VPNs. It would be a paramount security hazard. A more common usage of shared resources in a VPN is sharing some resources not belonging to each client. This is what happens in AirVPN too, where you share some resources inside the VPN, without never going out of the VPN itself. Specifically, a client in AirVPN can use DNS inside the VPN (no query of the client gets out of the VPN itself), and access other (different than ICANN) namespaces. A client accesses also other resources (geo-routing / micro-routing etc.), always inside the VPN. We might also add additional shared resources inside the VPN in the future. With a proxy, you never share resources inside a virtual network, simply because you are not in a virtual network. The similarity you mention might be born by a confusion. When the VPN offers also a gateway to other networks, as AirVPN does, the client traffic passes through different private and public IP addresses before its traffic is routed to the final destinations from the public, exit-IP address. What happens with a proxy is profoundly different, and the similarity is misleading: the traffic that's sent through a proxy never enters a virtual network, is not necessarily encrypted between your node and the proxy node, is only a part of your system traffic (only TCP), and continues its route to the Internet from the very same public address some application in the system sends the packets to. Your system default gateway and routing table remain the same and your system does not have another network interface to rely on. Some significant examples which show how this difference in behavior is very important are also mentioned in the rebuttal and cover the predominant usage of our service, if not the totality of it. As an additional, side note, it remains to be seen how and if a proxy can prevent spoofed packet injection in your DNS queries and in incoming traffic content with the same effectiveness provided by our service, as well as in fake personification based attacks. Kind regards

No, and you will be unable to punch a hole. Your OpenVPN client will refuse connections to begin with. However, as you know, data to and from HTTPS servers will be compromised and visible, if you allow them to poison the chain of trust of your system (often, in a corporate environment, the employee/office computer, property of the company, is already compromised, of course). It is already, have you tested it? With Eddie, use SSL tunnel to port 443, entry-IP 4 (when you configure this connection mode, you will see that only Castor and Chara will be available, all the other servers will appear in red and not available). Kind regards

Hello! Totally correct. To go further, in Eddie we have even removed the server certificate verification in stunnel, because the additional SSL/TLS tunnel is not required to provide data protection or integrity. It must only punch a hole through which then OpenVPN can break free. All the packets security and integrity is up to this second OpenVPN tunnel inside the stunnel tunnel. So, we don't want that stunnel verifies the certificate and breaks the connection. Let the censors and the voyeurs believe that they can inspect your traffic through the certificate hoax, and use this fact at your advantage. You just need to be aware that they can detect OpenVPN fingerprint (this issue can be resolved with tls-crypt, which is currently available on Chara and Castor only but will be widely deployed later in April and early May). Kind regards

It sounds like a bug, can you help us reproduce it? Describe a step by step procedure to reproduce the bug with Eddie 2.14.2beta please at your convenience. Remember, though, from your description it looks like you have white listed a country, and then black listed a series of servers. When you define two lists, one for the countries and one for the servers, the servers list takes precedence over the countries list. That's intended (we prefer this logic now: older Eddie versions performed an intersection of the lists and this caused a lot of confusion on users). Kind regards

@hugomueller Hi, can you please publish a full system report as well? "Logs" > click the life belt icon > copy all > paste in the message Kind regards

Hello! We will put this issue on the table of the lead Eddie programmer with high priority. At the moment there are no hotkeys to select the buttons you mentioned and we will seek for a solution that can be quickly implemented, if possible even in the next release which is imminent. Kind regards

Hello! That's correct. Each Air VPN server runs its own DNS server. If you query our DNS, the queries never get out of the tunnel, so you have a guarantee that they can't be hijacked or forged. Additionally you have some advantage in terms of performance, since you don't need that our servers forward the queries to a third party DNS which is outside the VPN. Kind regards

Hello, both screenshots show that your system does not have any traffic leak. Screenshot 2 shows that IPv6 is working on the server, while screenshot 1 shows that it's not. It's the same server, however, don't assume that IPv6 will always work as long as we don't officially announce full IPv6 support (which will allow you on most servers to reach IPv6 services even if you have only IPv4). Kind regards

Hi, SSH is over TCP, so it's not relevant in this case. Again sorry for the annoying lack of precision with SOCKS5. Well, at least it does not change the essence and the meaning, i.e. you just can't tunnel the traffic of an UDP only application with a SOCKS5 proxy, because you need TCP to establish the connection and give the SOCKS5 proxy all the instructions on how to route the subsequent UDP packets etc. If you come to know about a working proxifier that implements real UDP support with a remote SOCKS5 proxy feel free to let us know. Kind regards

Hello! In general the comparison was made with proxies which could offer encryption, so in reality only with HTTPS proxies, which do not support UDP at all. Sorry for the imprecision. Just out of curiosity, anyway the UDP support of SOCKS5 proxies is quite problematic on the "client side", even if you decide that your UDP stream does not need encryption. The initial handshake must be in TCP, not in UDP. This cuts out any application which can send and receive UDP only. An additional application (a proxifier) needs to tell the SOCKS5 proxy (in TCP) to forward UDP packets (on behalf of the application which speaks only UDP) until the TCP connection is closed, and it also needs to tell the proxy where to forward those UDP packets to. The proxifier application (or maybe in the future the built in proxifier included in an UDP software) would therefore need to do a lot of more job. So not only you need a SOCKS5 proxy correctly configured to forward UDP packets according to the instructions received in TCP, but you would also need a proxifier that implements such support, which is currently unavailable. It is very problematic and inefficient, because you still have a TCP "channel" that must direct operations. It's tested. more secure and faster to just wrap UDP into UDP with OpenVPN, forget TCP and not worry about re-implementing timeout handling, packet re-ordering etc. (all features widely peer reviewed with OpenVPN). And above all you don't send out an UDP stream in clear text. See here for a more detailed analysis: https://stackoverflow.com/questions/20976189/how-can-we-set-up-proxy-server-dealing-with-udp-packets Kind regards