Staff

@Rhenus Hello! Does "Same issue" mean that port forwarding stopped working for a while and only for some ports, and after a few hours started working again regularly, as @elcr reported? @elcr Is it still alright now? Kind regards

@Karmatron Hello and thank you for your tests! Bug causing memory leaks was found out and fixed. Memory leaks should not occur anymore in Eddie 2.21.3 (available since a few days ago) according to thorough tests, can you please test too? Keep us posted in the main thread! You can expect a stable release when all reported bugs have been solved and no new bugs emerge in a given time frame decided by the developer. As you can see, the latest version is much closer to a stable release. Kind regards

Hello! Unfortunately a set of names for your purpose has not yet been defined, we're very sorry. We will consider to fix the fault. At the moment, If you need them you can use the Configuration Generator (*) or open a ticket (specify the list of servers). Kind regards (*) Make sure to tick "Advanced Mode", so that you can see and select some connection mode ending to entry-IP address 3.

@SomewhatSane Hello and thank you! Just to balance somehow your point of view: have you have ever seen M247 servers operated by AirVPN withdrawn by us for some controversy related or not related to the behavior of our customers? We answer for you : it never happened. The same can not be said of numerous, other providers with which we have had controversies pertaining to net neutrality, allowed protocols, traffic monitoring and more, controversies which often disclosed contractual breaches by the provider or "strange" interpretations of ToS and/or AUP and/or contract, and consequently forcing AirVPN to drop the server and any commitment. Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s full duplex server located in Dublin, Ireland, is available: Minchir. 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 for OpenVPN and ports 1637 UDP for WireGuard. Minchir supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. 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/minchir Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! We're very glad to announce a special promotion on our long terms Premium plans. You can get prices as low as 2.20 €/month with a three years plan, which is a 68.6% discount when compared to monthly plan price of 7 €. You can also send an AirVPN plan as a gift: you have the option to print or send a colorful, dedicated picture with the code to activate the plan. You can do it in your account Client Area -> Your membership: Purchase and credit -> Print X-Mas after you have bought a coupon. If you're already our customer and you wish to stay aboard for a longer period, any additional subscription will be added on top of already existing subscriptions and you will not lose any day. Please check plans special prices on https://airvpn.org and https://airvpn.org/buy Kind regards & datalove AirVPN Staff

Hello! We're very glad to inform you that Release Candidate 1 version is now available. It's a minor update from beta 1 version: a specific manifest permission has been added to allow app black and white traffic splitting aimed lists proper population on Android 11 and 12. Many thanks to the tester who spotted the problem in latest Android versions! The post has been updated to link to the latest RC version. Special thanks to all testers who helped us in the alpha and beta stages! Please keep testing and report malfunctions and bugs, thank you in advance! Kind regards

Hello! Network Lock is a set of firewall (pf) rules so when Eddie crashes the rules remain unchanged and no traffic leaks outside the tunnel can happen. Also note that if Eddie crashes, OpenVPN or WireGuard can keep working without problems, so your system can still be in the VPN regardless of the crash. The only way to cause leaks after Eddie crashed with Network Lock would be (on top of killing OpenVPN or WireGuard) changing firewall rules, but only superuser can do that. That said, the idea to test Eddie beta version is good, please keep us informed. Kind regards

Version 2.21.3 (Wed, 15 Dec 2021 11:35:46 +0000) [change] [windows] WireGuard 0.3.11 > 0.5.2 WireGuardNT/0.10 [change] [windows] Important fix about crash after many hours with WireGuard [change] [windows] "Recovery, unexpected crash?" false positive in some circumstances [bugfix] [linux] Updated Portable and AppImage bundles for better distro compatibility [change] [linux] Constant monitoring of /etc/resolv.conf during connection [change] [windows] Better management of network adapter creation & destruction [new] [all] "Upload to paste URL in support ticket" in Lifebelt

@organicchocolate Hello! You don't need to rush to pull the plug and/or attend and monitor the VPN connection continuously if you enable Network Lock, which will prevent any possible traffic leak outside the VPN tunnel even when Eddie crashes. For all the other, numerous problems of Eddie 2.20 in Monterey, please follow this very thread: upgrade to Eddie 2.21 beta, apply the Apple "patches" (at least until a new Monterey fixed version is available) and all the problems should get resolved according to the reports. Kind regards

Hello! In our case, to collectively answer many requests and mitigate the amount of future tickets about it. Kind regards

Hello! We would like to inform you that we have never used the Apache Logging Services and/or Java in general, so any Log4j vulnerability, CVE-2021-44228 included (overall CVSS score 10.0 - critical) doesn't affect AirVPN web site or anything related to AirVPN. https://nvd.nist.gov/vuln/detail/CVE-2021-44228 Kind regards and datalove AirVPN Staff

@rock3716 It's an interesting case for us too. It's a very odd behavior by the provider, because it poses mere conduit problems (*). If a hosting provider intervenes to censor the content published by a customer without solicitation by a court order or at least a communication by a third party, it means they have editorial control, so they might be held liable (secondary liability) for the content published by their customers. In the reply, they clearly admit that they intervene against disinformation and misinformation, and suggest that a crime has been committed ("endangering public health"), as if they were omniscient to decide what disinformation and misinformation are, and they have the ability to monitor all the content of all of their customers. A safer approach for them would have been reporting to the competent authorities to decide whether something infringes the law or not, ensure to the publisher of the content the right to a defense, and optionally make the content unavailable while the case is ongoing. because of a third party warning, and not for their ability to check everything in their infrastructure uploaded by customers. Tons of things must be verified, but if the reports and the reply are authentic and not fake, the provider is walking on a slippery slope: apparently it is naively operating to hog editorial control, a catastrophe for any hosting/housing provider etc. (*) Directive 2000/31/EC has been transposed not only in the 27 EU Member States, but also in iceland, Norway and Liechtenstein.. Kind regards

@OpenSourcerer Hello! There is no middle-ground, either you use VPN DNS or you use Firefox DoH and renounce to some AirVPN features. Well, to say it all you can also use DNS over HTTPS or DNS over TLS with the Air VPN DNS, they are both supported, but it does not make much difference because the DNS queries remain in the tunnel even without DoH or DoT (anyway we support them both for the comfort of those users who set peculiar configurations). Surely we can improve the description, but it's not that simple, i.e. it can't be limited to DNS block lists, as other considerations such as geo-blocking feature and route hijack attack immunization should be described when one renounces to VPN DNS. We enter a sticky situation, because the advanced user already knows it all, while the beginner might be unable to understand it from a synthetic description and might join that choir of donkeys (initially formed because we refused and refuse to pay ransoms for reviews) braying that AirVPN is too complex to use. Excellent. The paper authors can't understand or accept our point of view (which pj explained in private before the paper was published when queried, but no replies came in after the explanation) but it doesn't matter, what it matters most is that our core community, advanced and/or long time users, understand why our choice makes sense and is based on good design. Kind regards

Hello! Thank you for your answers. There's just a terrible misunderstanding we can infer from one of them though (quoted), which we would like to fix. The user can, and have always been able to, disable this feature by not using Air VPN DNS, as usual. It takes a few seconds to configure it in Eddie Windows edition. By not using Air VPN DNS they will have no more NXDOMAIN returned by "use-application-dns.net" resolution (unless of course they force some other DNS that does ), as specified in our https://airvpn.org/specs page. What the authors of the paper consider a problem is probably caused by the fact that they don't like that the feature is "opt-out". But we need it otherwise we would have hundreds (thousands?) of customers complaining (and rightly so!) of alleged DNS leaks, complaining that DNS block lists don't work, complaining that geo-routing doesn't work. It's our opinion that the current implementation is good design, not poor design as claimed by the paper authors, whose consideration is frankly very questionable, again in our opinion. Our case is exactly foreseen and described by Mozilla in the list of cases for which default DoH in Firefox must be disabled. "Risks: [...] When enabling DoH by default for users, Firefox allows users (via settings) and organizations (via enterprise policies and a canary domain lookup) to disable DoH when it interferes with a preferred policy. ". In our case the preferred policy is letting the users take advantage of geo-routing, DNS block lists, as well as defusing the extremely dangerous route hijack attacks by making the DNS server address matching the VPN gateway address, and providing users with peace of mind when they test for "DNS leaks" through web sites etc. Such strong AirVPN features should remain "opt-out" and not become "opt-in", as they are not only a fairly required part of AirVPN features but also an important security addition. Those who still want Firefox DoH can simply disable DNS check and reject DNS push, or force any public DNS in Eddie, because they would not use VPN DNS in any case, obviously. Kind regards

Hello! We consider bypassing DNS strictly picked by the user a bad practice, while the paper authors consider bad practice basically the opposite. Anyway, it must be said that the paper says "doing so [disabling DoH} without reasons is considered poor practice". Of course AirVPN does it for a reason which in our opinion is strong and valid (you can infer it from the questions below), so the sentence should not be considered a negative evaluation of AirVPN software for Windows. Please feel free to open a debate, we are very much interested in it. Some questions from us, we would be glad if you could answer freely: Should a browser be able to bypass your own DNS choices and hijack your queries to third-party DNS servers whose privacy, logging and neutrality policy you may or may not have read (*)? If you answer "yes" to the previous question, should it do it even without your knowledge by default, or should it offer this feature as "opt-in"? If you tell a VPN client to use the VPN DNS only, should the VPN client have the ability to disable browser's DNS bypass, or not? (*) For example Firefox enables DoH even if you have not been informed about who are the third party DNS your queries end up to, by whom they are operated, and what their policies are. Kind regards

Hello! We're very glad to inform you that beta 1 version is now available. It includes a lot of new features and improvements, as well as important bug fixes, that you can find on the first post, where a complete changelog has been pasted too. The post has been updated to link to the latest beta version. Special thanks to all testers who helped us in the alpha stage! We are now much closer to a stable release. Please keep testing and report malfunctions and bugs, thank you in advance! Kind regards

@rnd227 Hello! The Master Password is used by Eddie to encrypt and decrypt sensitive local data and it's not related to your AirVPN account password. You pick the Master Password the first time you run Eddie, while you pick AirVPN account password when you register your account in the web site. You enter the Master Password when Eddie is first run in an Android session, while you enter your AirVPN account password to log the account in to AirVPN infrastructure. In Eddie Android edition version 2.4, the Master Password is mandatory. Starting from Eddie Android edition version 2.5 (currently in public beta testing) Master Password is disabled by default and can be optionally enabled and disabled. Kind regards

Hello! Very important indeed. Thank you very much for the report! Kind regard

@NoMercy1290 Thank you! The problem has been resolved. Kind regards

@Air4141841 Hello! That's correct, FQDN records pertaining to the "best" server of a certain area (country or continent or planet) are updated every 5 minutes to make the name resolve into the "best" server entry IP address in that area. "Best" server is computed by a simple formula which takes into account server load (connected clients), available bandwidth, ISP reliability and round trip time between the server itself and all (or many) other VPN servers in AirVPN. @kbps IPv4 private subnets are inside three possible ranges: https://en.wikipedia.org/wiki/Private_network#Private_IPv4_addresses You can find the one your devices are in by checking the router settings, for example, or the physical interface settings of one of your computers Kind regards

@JamesFrancis Hello! In this case please avoid Kitalpha and Xuange at the moment. Do not rely, therefore, on generic ch3* FQDN but connect to a specific server which works for you in IPv6. Kind regards

Hello! On top of what @OpenSourcerer correctly wrote, also consider that major Linux distributions run with obsolete packages which are kept on their repositories, with internal maintenance mainly dedicated to security patches only. For example Debian 10, which was the latest stable Debian until few months ago, has OpenVPN 2.4 in the repository (and archaic kernel and libraries...), and Debian 9 ("oldoldstable" still supported and widely used) runs OpenVPN 2.3. Not many users take care of a backport, even less to build latest OpenVPN version inside their distribution. Kind regards

@Heliotropen Hello! The problem you experience might be caused by the "pre-Catalina" version, i.e. the package signed and notarized for macOS systems older than Catalina, when it is installed on macOS Catalina and newer releases. Can you please check? Kind regards

@JamesFrancis Thank you. Your ISP supports IPv6 for sure because connections to NL servers over IPv6 are successful. The failure to Swiss servers in IPv6 can be caused by lack of IPv6 support on our side. In Switzerland, Kitalpha still lacks IPv6 support because the datacenter does not support it. Other servers might be having IPv6 "black out" intermittently. Unfortunately you censored too much, yes, you removed the entry address of the VPN server you were connecting to, so nothing else can be said at the moment. : Maybe if you connect over IPv4 you will resolve all the issues. Kind regards