Staff

Hello! We inform you that for datacenter needs, IPv4 and IPv6 addresses assigned to Alkes, Merope and Sabik will change on Aug, 12 2019 at 11.00 UTC. If you run Eddie, you don't need any specific procedure, as Eddie will update data automatically and periodically. If you use some OpenVPN profile that's specific to one or more of those servers, please generate a new one through our Configuration Generator. Kind regards AirVPN Staff

In this case the "problem" does not exist, as what you define as "forcing" is in reality an ordinary DNS push performed by the VPN server. DNS push informs your system what IP address the DNS server has in the virtual network (if any) but does not force it. OpenVPN client for BSD and Linux systems by default ignores the DNS push, while OpenVPN for Windows accepts it. Eddie by default accepts it (on all supported systems), but you can tell it not to do it in "Preferences" > "DNS" > "DNS Switch Mode" (when you disable the switch, remember to untick "Check Air VPN DNS", otherwise Eddie will correctly check the DNS usage and throw an error, and set your favorite DNS server address(es) in "DNS Servers" field). You have total freedom about how to handle the DNS push: it's an optional, not a forced feature. Enjoy AirVPN! Kind regards

It's a security feature. When the DNS IP address matches the VPN gateway IP address the notorious attack based on DNS hijacking and route injection, which most commercial VPNs are vulnerable to, becomes impossible. https://www.researchgate.net/publication/274800185_A_Glance_through_the_VPN_Looking_Glass_IPv6_Leakage_and_DNS_Hijacking_in_Commercial_VPN_clients Note that the paper cites AirVPN, but that's a paramount error, as the researchers did not fix the paper, not even after we repeatedly warned them about their mistake. We are not aware of any negative consequence, please feel free to elaborate. You are anyway free to query 10.4.0.1 in case you don't like the security feature for any reason. Address 10.4.0.1 is reachable by DNS queries from any VPN subnet. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Singapore (SG) is available: Lacaille. The AirVPN client will show automatically the new server; if you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Lacaille supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/Lacaille Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

@HannaForest Hello! More simply, by using Tor (either Tor over OpenVPN or OpenVPN over Tor, supported by Eddie desktop editions) or using two connection slots from the same machine (for example with the aid of a VM attached to the host via NAT). First solutions are better because you don't multi-hop on servers all belonging to the same company (AirVPN). Kind regards

Funny marketing fluff. Since AirVPN birth we allow multi-hop connections (opt-in) between different VPN servers, between VPN servers and SOCKS or HTTPS proxies, or (better solution) between VPN servers and Tor nodes. Safer and better than marketing fluff. HOWEVER, it must be known that there are some errors in the article you linked. It mixes at least two totally different attack types and makes a lot of confusion. Timing attacks can be performed anyway even on Tor network (in any low latency mix based protocol network, in general) given an adversary with enough power to monitor vast portions of the Internet., so the general analysis provided by the article is... imaginative, to say the least. Kind regards

Hello, can you please post a complete system report generated by Eddie? "Logs" > LIFE BELT icon > Copy All button > paste into your message (remove sensitive data if any). Kind regards

Hello! 1) Network Lock is not meant to survive a reboot. It's an intended behavior and a very wise decision. 2) Network Lock will remain enforced if Eddie crashes, contrarily to what you claim. It's a set of firewall rules. BUT of course if Eddie crashes at the very start then of course Network Lock will not be set. 3) If you wish that your system is always isolated from the Internet during bootstrap, set a permanent firewall rule (or two, if you have IPv6) blocking all outbound traffic. That's all, because when Network Lock is activated, Eddie will rewrite rules to allow communications to Air VPN servers. Similarly, when Network Lock is disabled by your command, Eddie will restore your previous firewall rules, which will block again all traffic (so you don't need to worry not even during the shutdown). Kind regards

Hello! In order to avoid confusion, we have changed our GitHub repository name into openvpn3-airvpn. URL has changed and has been edited accordingly in the first thread post. Kind regards

We also confirm that Eddie runs just fine in Ubuntu 18.04 with an exception: if you use systemd-resolved with on-link DNS, Eddie will be unable to force usage of VPN DNS. Since Eddie acts on /etc/resolv.conf and systemd-resolved takes total management of resolv.conf (see https://wiki.archlinux.org/index.php/OpenVPN#DNS ) Eddie operations on DNS will be ignored. At the moment you can revert to normal UNIX handling of global DNS. In general the aforementioned, very dangerous abomination is only harmful when you use a VPN, because it has the power to give birth in Linux for the first time in history to "DNS leaks", which were notorious only in system without a global DNS like Windows. Kind regards

It doesn't. The problem is on your side. Everything works as it should on Telescopium. It's not the first time you charge to us a problem on your side, and from that you jump to defamatory conclusions and widespread forum trolling before even you open a ticket. Since you re-iterate the same mistake repeatedly, we don't think anymore that you are in good faith. To avoid any further FUD and trolling from your account in our forums we will act accordingly.

Hello! Please make sure that your system queries VPN DNS, then please post a traceroute to the host while connected to Telescopium. From a terminal: traceroute <destination IP address> "traceroute" is "tracert" in Windows. Kind regards

@laowai Hello! We're very glad you can confirm the outcome of our tests as well as reports by AirVPN users, also published in this thread. Great! Our roadmap includes availability of OpenVPN 3.3 AirVPN binary, with some client side nice additions to make the experience more comfortable. in the following systems: Linux (binaries for both x86 and ARM processors) during August 2019 FreeBSD OpenBSD in the above order. Desktop systems with AES-NI full support decrease performance with ChaCha20 encryption/decryption when compared to AES-GCM, so ChaCha20 will not be a favorite choice by those users who already enjoy AES-NI. Therefore: our priority is releasing binaries which will be particularly useful in ARM based devices, which typically run on Linux or *BSD. ChaCha20 might perhaps provide higher performance (than AES-GCM with AES-NI), with coming (in the near future) CPUs featuring AVX512, it will be interesting to test. Additionally, in desktop systems you can already run OpenVPN 2.5 beta which supports ChaCha20 on the Data Channel, while on some embedded devices building OpenVPN 2.5 may be out of the ability of the average user. You can even integrate OpenVPN 2.5 beta in Eddie desktop editions, as Eddie can be configured to use any OpenVPN binary file in "Preferences" > "Advanced" > "OpenVPN Custom Path". You then need to add the following custom directives: ncp-disable cipher CHACHA20-POLY1305 in "Preferences" > "OVPN directives", and finally connect to one of our experimental servers. By using Wireguard on Android devices, you already have roughly the same battery life you experience with Eddie Android edition which uses OpenVPN 3.3 AirVPN linked against mbedTLS, on equal terms (same bandwidth, traffic, etc.). Please feel free to report back if you experience some discrepancy, i.e. if you see longer battery life with Wireguard. Anyway we are following Wireguard closely. Currently we need a couple of new, key features, which will probably be implemented before a stable version is released, as developers told us. Without them, implementation in our systems is too problematic. For example, linking static IP addresses to client keys is a heavy threat to privacy, for the reasons we explained in another thread; and lack of TCP support would cut out a remarkable amount of our customers, whose ISPs disrupt UDP. Kind regards

@airnoob Hello! This will be fixed for sure. We will not repeat the same mistake, trust us. Stop, you misunderstood the whole matter: the patch fixed the corruption of the configuration file which was caused by the bootstrap servers output. It was not something to be fixed in the code of Eddie desktop editions, apart of course designing a software which handles in a better way corrupt configuration files. The bootstrap servers were reconfigured with a new manifest format which introduced a bug: when someone tried to log the account in without having a valid plan, the bootstrap servers returned a bad message format that caused the corruption of the default.xml file of the user who did not have a valid plan. The bug was fixed quickly in the bootstrap servers. The patch you mention fixes corrupt configuration files on the client side, as an alternative to delete them. Not essential, just an additional tool for those Windows users who tried to access the service without a valid plan. Yes, you had better stop speculating. Clodo is an Air co-founder so your assumption is wrong. We will let Clodo explain the exact reasons of such delays in development, if he wishes so. Here we just point out that any excessive work load on some department is being quickly balanced to avoid any further problem of this kind. AirVPN has both the resources and the will to continue delivering the best VPN experience in the consumers' market as it has always done in the last 8 years. About the last year you mention, you can note that AirVPN has delivered from scratch not only an Android application with unrivaled features, but it is the only VPN which actively develops OpenVPN 3. AirVPN has added to OpenVPN 3 missing features that were never seen in it after years and years of development, like ChaCha20 cipher on the Data Channel. No other VPN service has ever achieved the same results. Kind regards

@airnoob Eddie desktop edition development is up to Clodo and we have reported the roadmap in other threads. We leave further details to Clodo himself if he wishes to add anything. There's no doubt that several issues need to be fixed and they will be fixed. Nothing has been abandoned. For issues pertaining to Ubuntu 18, please open a ticket and it will be handled by developers. Political nonsense is your opinion. If you want to insinuate that our support to freedom of expression is out of the scope of our mission than we completely disagree. We remain convinced that our actions of any kind are fully compliant to our mission, and even mandatory under some respect, in consideration of the attacks against fundamental rights which are unprecedented in "Western" countries in the last decades. None of our actions in support of freedom of expression impacted Eddie desktop edition development in any way. About projects assigned to ProMIND, they are all confirmed, in particular: further development of Eddie Android edition further development of new features on "OpenVPN 3.x AirVPN", on top of the already available ChaCha20 cipher on the Data Channale, new class supporting any AEAD cipher and ncp-disable directive development of new software for platforms based on Linux. FreeBSD and OpenBDS (OpenIndiana is under consideration), in this order MacOS will be part of the development for FreeBSD (various BSD elements on Darwin make the development for Mac partially compatible with ProMIND assignments with no over-complications, according to an initial overview) the new software for the aforementioned systems will initially couple Eddie, will use "OpenVPN 3 AirVPN" library (while Eddie will remain on OpenVPN 2 branch) and will not be tied to Mono in any way It's important to underline again the the above projects have been, are and will be managed without subtracting any resource from Eddie desktop editions development. They are completely separate "branches" with their own, parallel and independent resources. Kind regards

Hello! The datacenter operations might be impaired by the charges against the datacenter management issued on last June and related to crimes allegedly committed in 2012: https://www.cp24.com/news/owners-of-toronto-web-hosting-company-charged-in-massive-child-pornography-bust-1.4474497 Although our VPN servers in that datacenter have still IPv4 connectivity, only on some IP addresses, we can't of course count on them reliably. We are therefore shutting them down. Infrastructure in Canada remains with 31 servers capable of 1 Gbit/s bandwidth each, which provide wide redundancy, and we will anyway enlarge it whenever necessary. Kind regards

Hello! Your ISP can't detect the traffic type (protocol, application) in the VPN tunnel. Also, your ISP can't detect remote ports for your incoming connections, those are VPN servers ports and your local network interface ports. When the traffic passes through your ISP network it's still or already encrypted. Kind regards

Hello! Multiple connectivity problems are still affecting all the 6 servers. We have no communications from the provider so far. Kind regards

Hello! Servers connectivity has been partially restored. IPv6 is still unavailable and entry-IP addresses 3 and 4 seem unreachable. Kind regards

Hello! We're very glad to inform you that we have now activated a Singapore server running OpenVPN 2.5 supporting ChaCha20: Luyten, it will make connections from various Asian locations quicker. Kind regards

Hello! We regret to inform you that we have been unable to contact one of our providers in Canada since 24 hours ago. All of its servers are down as well as its web sites. Affected servers are the following five: Almach Dheneb Grumium Kraz Rana Spica Luckily infrastructure redundancy is so high in Canada that lack of those five servers will not impact quality of service. We will update this thread with future developments, as soon as we receive any kind of information. Kind regards AirVPN Staff

Hello! On average Vancouver servers are 70% free. Bandwidth peaks do not exceed 50% availability. Demand for Vancouver bandwidth is still well within infrastructure redundancy. Kind regards

Ignore the previous message, we can infer the class of your OS from a line of the crash. Please try this: open a terminal in your Mac type the command sudo rm ~/.airvpn/default.xml run Eddie "default.xml" is Eddie configuration file and from the crash report we suspect it's corrupt. Eddie will re-create a new "default.xml" configuration file at the next run with default settings and the problem should be resolved. Kind regards

Hello, what is your Operating System name and version? Kind regards

Hello! On the server side we run OpenVPN 2.5 to offer ChaCha20-Poly1305 on the Data Channel. OpenVPN 2.5 is still in beta testing, although some key functions are performed by OpenSSL or mbedTLS which are stable, so we mark servers running OpenVPN 2.5 as "Experimental" (you will see them listed with the yellow warning color). OpenVPN 2.4.7 does not support ChaCha20 on the Data Channel so it's a no go (note that OpenVPN 3 is a library with client only, and not server, features). When OpenVPN 2.5 stable version is released, then ALL of our servers will support ChaCha20 on the Data Channel. Estimated release date is November 2019 according to OpenVPN community. In the meantime please feel free to use ChaCha20 on the experimental servers, of course. We can expand the network of experimental servers if we receive requests. Currently the servers in Canada and the Netherlands seem enough to support the traffic of clients using ChaCha20, but please let us have your feedback! Kind regards