Staff

It looks like that different IP addresses cause different behavior (or access different backends, or something like that). From Netherlands VPN servers the long-awaited "time menu" is finally visible, but sometimes it does not work well and usually does not work at all. From non-NL servers, the menu seems not acccessible at all (at least at the moment of this writing). Kind regards

Hello! We think that three simultaneous connections from any network / IP address without any limitation on each connection slot is enormously more valuable than five simultaneous connections only from the same network. what do you think?

https://duck.co/forum/thread/1678/filter-search-results-by-date But keyword "sort:date" does not work, apparently. https://duck.co/help/features/dates This again relies on Google, it's not a solution...

so if you live in a country which tries to disrupt vpn technology, the state just needs to cache all exit ip adresses of popular vpn services and you are done, right? No: blocking exit-IP addresses would have an impact only on services inside that country, but would allow a citizen to connect to our VPN servers and go out on the rest of the world. They would need to harvest different IP addresses (entry-IP addresses of course, and many other ones that of course we will not mention here). Additionally, you can easily imagine a way to circumvent even this block if you think about all the connection abilities of OpenVPN, even cited in this thread... Kind regards

@coconuts What exact Debian distribution version are you running? Kind regards

You need to tell Linux to use the AirVPN DNS server. Or set things up to make the change whenever the OpenVPN connection is started or stopped. See: https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/ In the past, staff have called this a "misconfiguration" (or something like that), rather than a "leak". The difference between Linux and Windows is that for Linux you do it once in one place. For Windows you have to do it for each interface. Arguably an absurd feature, responsible for the labeling of Windows as suffering from DNS leaks. Exactly, it is factually and definitely not a leak, under any possible point of view. Global DNS stands so even if OpenVPN client doesn't accept (in GNU/Linux) OpenVPN server DNS push, your DNS queries to DNS servers outside the local network will be "tunneled" in any case. This is a really remarkable difference between a system where global DNS is implemented and a system where global DNS is not implemented and default gateway for each interface is considered in DNS queries. Windows makes both things, that's why in Windows so called "DNS leaks" are real, physical leaks (packets not encrypted and routed via the "wrong" gateway). There is probably a way to configure a GNU/Linux system to emulate Windows DNS implementation, for didactic or exotic purposes, and force DNS queries go outside the tunnel regardless of the routing table, but this is an intentional "corruption" so it is not taken into consideration. Kind regards

That's based on the detected "fingerprint" by the final service, when packets are all out of the tunnel. It is a different issue than hiding OpenVPN between your node and the VPN server (typically where your ISP observes you). See WITCH for the original code http://witch.valdikss.org.ru/ At the moment you can make WITCH unable to recognize OpenVPN usage in UDP by selecting unusual mssfix parameters. Interesting to compare with this: https://airvpn.org/topic/17709-netflix-how-to-accessuse-it-when-vpn-is-connected/ Kind regards

You can quickly copy the logs to the clipboard by clicking (from Eddie main window) "Logs" > "Copy to clipboard". Alternatively enable logging to file in "AirVPN" > "Preferences" > "Advanced" > "Logging" and then access the log file, for example with any text viewer or editor. Kind regards

It compares your system IP address with all the Air VPN servers exit-IP addresses. Kind regards

Such Windows messages are ambiguous and sometimes over-agonizing, are you sure that it was not just a DNS problem? Windows diagnostic tool will shoot alarming error messages even when the only problem is that the system can't resolve names. And sometimes it will suggest to revert to some previous system wide restore point just because of a simple problem in network interface DNS settings that could have been solved in a matter of seconds. Have a look here and make sure to always shut down the Air software properly (don't kill it without grace, or it will not be able to restore your system settings until the next run): https://airvpn.org/topic/14829-can-only-connect-to-the-internet-browser-through-airvpn/?do=findComment&comment=30509 Kind regards

While Tania passed the tests successfully for days and days, as soon as we put it public it started having a bunch of problems, including high packet loss with most of our other servers. Then, it became unreachable from most of the Internet. We are waiting for datacenters technicians investigation, anyway we are ready to withdraw it if the problem is not solved in the near future. Kind regards

Hello! Please see here: https://airvpn.org/topic/11208-in-what-order-the-client-choose-recommended-servers/ Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Dallas, US-TX, is available: Auva. 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, 2018 UDP and TCP. Just like every other Air server, Auva 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

Which leads me to my next question. If VPN servers use your current network as a passthrough to another network, why is the passthrough network the one that takes it up the ass when it comes to legal issues? Usually it does not. Apart from considerations of liability exemptions due to mere conduit status, safe harbors and similar terms used in other legal frameworks, usage of a VPN tends to reduce to zero any liability of the original "passthrough" network, because traffic is encrypted and any third-party entity sees any infringement coming from the VPN, not from the "passthrough", physical network. Usually, as far as we can understand, different reasons lead to protocol/applications blocking: marketing reasons (for example profiling purposes, ads through packets injections, DNS poisoning for a myriad of reasons - all of them become impossible with a VPN) and traffic management (effective traffic management becomes virtually impossible with a VPN). Kind regards

Hello @Whiskey_76 According to this: it appears that system tries to load the lib from /usr/lib (and it does not find it) instead of the current working directory. If you are 100% sure that your cwd was the same in which airvpn is in, and that you decompressed the WHOLE tarball in that directory, this issue needs to be investigated by the developer (a possible workaround would be the creation of symlink). Can you show the whole content of the directory which you decompressed the tarball in? Kind regards

Hello, yes, we are working on it. Kind regards

Hello! We're very glad to inform you that five new 1 Gbit/s servers located in the United Kingdom are available: Alathfar, Betelgeuse, Denebola, Kitel and Minkar. The AirVPN client will show automatically the new servers, 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 new servers accept connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Alathfar, Betelgeuse, Denebola, Kitel and Minkar support 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

You have been given repeatedly proof that the problem is on your side (either in your ISP infrastructure or in your ISP transit providers, we can't know up to this fine grain details), please consult the replies to your previous tickets on the subject. If there's something unacceptable, it's the pernicious obstinacy to ignore facts when they don't fit in some theory. Kind regards

Irrelevant. That test would include anybody using OpenNIC DNS etc. Harvesting all exit-IP addresses of AirVPN servers is a much faster and reliable way to discover whether someone is behind an AirVPN server. Kind regards

Hello! We're very glad to inform you that five new 1 Gbit/s servers located in the Netherlands are available: Alphard, Alphecca, Alphirk, Alzirr and Asellus. All of these servers have direct peering with AMS-IX, meeting a need that arose for some customers since when we dropped Leaseweb in Amsterdam. The AirVPN client will show automatically the new servers, 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 servers accept connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Alphard, Alphecca, Alphirk, Alzirr and Asellus support 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're very glad to inform you that a new 1 Gbit/s (*) 100 Mbit/s server located in Hong Kong is available: Tania. 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, 2018 UDP and TCP. Just like every other Air server, Tania 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 (*) We apologize for the error in this message. This server is connected to a 100 Mbit/s line, not 1 Gbit/s.

This is fine. A packet inspection tool inside your system can of course see traffic to/from the VPN while it has not yet been encrypted, or when it has been decrypted. When the packets are in the physical network interface of the system connected to a VPN server, they are encrypted, but on the tun/tap interface they are not, so you see them already/still unencrypted while they are in the tun interface. Kind regards Hi Staff - as you say, if it was only a packet sniffer on my PC that could see them, that would be ok. But my firewall can see these requests unencrypted, and my firewall is a completely different physical system to my PC, with multiple routers and switches separating the two. So the requests are definitely being sent outside the VPN tunnel. Hello, surely the firewall is inside your LAN. That's perfectly normal (in Windows) due to the incorrect DNS implementation in this system. Note that 10.4.0.1 is set as primary DNS in every network interface (by Eddie), this is the explanation of what you observe, as already Zhang888 pointed out. Next release might handle differently this issue (with ValdikSS integration in the main OpenVPN branch of the directive fixing DNS leaks in Windows, or by setting a totally unroutable address in the network interface instead of the VPN DNS), but it's not so serious. An adversary that wants to attack you with DNS poisoning in a public hot-spot (in which the attacker controls the router/hot-spot and sends you wrong resolutions of queries leaked inside the local network) should know in advance that you would be sending inside the LAN DNS queries to 10.4.0.1 (which is also the VPN gateway, making other DNS-based attacks impossible). In the meantime just enable Network Lock and you will be protected even against this unlikely attack scenario. EDIT: an overview of the wrong DNS implementation in various Windows versions and the implications for users of a VPN is here: https://medium.com/@ValdikSS/beware-of-windows-10-dns-resolver-and-dns-leaks-5bc5bfb4e3f1 Kind regards

Hello, this is exactly the correct forum for warnings like yours. "Warn us here about websites you can't reach from our servers" is this forum description. Thank you, we'll see whether we can do something about it or not. Kind regards

Hello, we don't understand what the posters are trying to say, so let's fix all the fundamental errors in an attempt to have a background with correct information. The VPN subnet(s) is/are not and has/have never been 10.0.0.0/9. Please see https://airvpn.org/specs This is not true. In addition to the above error, even if the specified subnet was correct (and it is not), the sentence appears to assume a flawed definition of "tunnel" which hints to a basic misunderstanding on how traffic is routed. The "tunnel" is defined by the routing table and the default gateway, not the other way round. 10.58.x.x is not the IP address of any VPN DNS server and is not even within any subnet of the virtual networks. This is fine. A packet inspection tool inside your system can of course see traffic to/from the VPN while it has not yet been encrypted, or when it has been decrypted. When the packets are in the physical network interface of the system connected to a VPN server, they are encrypted, but on the tun/tap interface they are not, so you see them already/still unencrypted while they are in the tun interface. Kind regards

Benetnasch is detected by maxmind/ipleak in Norway (no), but physically it's in Sweden (se). Rastaban is detected by maxmind/ipleak in Norway (no), but physically it's in Sweden (se). Serpentis is detected by maxmind/ipleak in Norway (no), but physically it's in Sweden (se). Zaniah is detected by maxmind/ipleak in Norway (no), but physically it's in Sweden (se). Pherkad is detected by maxmind/ipleak in Finland (fi), but physically it's in Sweden (se). Persei is detected by maxmind/ipleak in the Netherlands (nl), but physically it's in the USA (us). Tegmen is detected by maxmind/ipleak as in the Seychelles (sc), but physically it's in Canada (ca). Virginis is detected by maxmind/ipleak as Proxy/Anonymous, but physically it's in Switzerland (ch). We have monitoring tools that report such incongruence between MaxMind and physical locations. We could make some real time view on status pages if it can be interesting. We are doing our best to correct this kind of issue, but honestly it's out of our control. @zhang888: Google Maps API as far as I understand doesn't have public IP geolocation services. If it's possible to query Google about how/where an IP address is geolocated, we can make the aforementioned chart list automatic and in realtime. Kind regards, Clodo