Staff

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

Hello! We're very glad to inform you that twelve new 1 Gbit/s server located in Sweden are available: Albali, Algieba, Algorab, Alrami, Altarf, Alula, Atria, Azmidiske, Benetnasch, Hatysa, Menkab and Muphrid. 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, Albali, Algieba, Algorab, Alrami, Altarf, Alula, Atria, Azmidiske, Benetnasch, Hatysa, Menkab and Muphrid 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. One of the servers in Sweden, Acubens, has been withdrawn from VPN servers. This was the server with the oldest hardware in Sweden and it is appropriate to replace it. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

You don't install anything. You just extract it from the compressed file and then run the binary. Which would be fine--if it worked at all. Hello, Eddie portable version not requiring Mono works perfectly in Ubuntu 16.04, so it appears strange that you find issues in Xubuntu. Your quoted reply is ambiguous, are you sure that you have decompressed the whole tarball (and not only a single executable file) into a folder created for the purpose? Kind regards

Hi, Clodo was and is the Eddie developer. There is currently no independent development of Eddie as far as we know. Perhaps it will happen, who knows, thanks to GPL. One of the most important new features in Eddie 2.11 is the compatibility with Mono 4.4. Kind regards

That's not a fork! Kind regards Care to elaborate? No fork has ever been initiated inside the Air staff. The source code you see in that official repository is in the Eddie main branch. The source code you now see for the 2.11 alpha release is the basis for version 2.11 (or higher) stable, as usual. Do you know about any fork of Eddie, by chance? Kind regards

Hello! We're very sorry, although we have a routing server in Australia, we can't solve the issue in any way because the SBS service uses a shared CDN (i.e. a delivery network that's shared between many different content providers): we can't micro-route any VPN server to it. Kind regards

That's not a fork! Kind regards

Hello, please run the portable version NOT requiring Mono. Kind regards

Hello, we see refused connections because packets are rejected, otherwise we would have seen timeouts (no replies at all from your client) as you correctly notice, not to mention the fact that your account expiration date was irrelevant: obviously we tested when your client was connected to some VPN server. Kind regards

Hello, make sure you have read the reply to your ticket, there is an important information which should help you fix the issue (we see packets reaching your system which are actively rejected). Kind regards

Hello, let's remain to the system message, because "TAP driver" runs in millions of Windows machines without causing page faults. If you can rule out any low level driver problem, the message suggests that you have some other problem in your system. Searching for: bsod Page_Fault_In_Non_Paged_Area netio.sys in Google Search returns 4400 results. The first returned pages are interesting, hopefully they can give you some useful hint to solve the problem. Kind regards

Hello, as you can see on the screenshot you posted, the system-wide crash has been caused by netio.sys. As a first step, make sure that the driver(s) of your network card(s) are all up to date. We would rule out that the Air software, running in the userspace and in the .NET framework, is capable to directly cause a Page_Fault_In_Non_Paged_Area and bring down the entire system. At most, it could cause it very indirectly, for example when low level drivers are already bugged. Kind regards

Hello, that's fine but it's just a part of the story, you also need to actually forward the packets, of course. Please see here: https://airvpn.org/topic/9270-how-to-forward-ports-in-dd-wrt-tomato-with-iptables/ Kind regards

Hello, it is indeed possible to make Network Lock working with AirVPN over Tor. It's currently not planned but it might be implemented in the future. Eddie already talks with Tor control to get the IP addresses of the Tor guards. This is necessary to set the proper routes and avoid the infinite route loop problem (so the user does not need any middle box). The circuit is fixed for the OpenVPN stream, so no additional problems should arise. Kind regards