Staff

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

@JamesFrancis Hello! Maybe your ISP doesn't support IPv6. Try an IPv4 connection. We asked for the log but we can't see it, can you please check? We mean the complete, unedited OpenVPN log showing the failure. It may help significantly. Kind regards

@airvpnforumuser Hello and thank you for your tests and the bug report! Please make sure that "Always on VPN" is enabled for Eddie, as it is a mandatory option to let a VPN app start during bootstrap in latest Android releases. If that option is enabled and the problem persists, can you please share with us the log as soon as you have manually launched Eddie? And if possible, it would be more important than the log, can you please send us the logcat starting from the initial bootstrap? Kind regards

@canmom Hello! On top of what @OpenSourcerer wrote, we add for your future reference (if necessary) that Goldcrest and any other Bluetit client can't override various explicit Bluetit settings enforced by bluetit.rc. The logic behind it is that bluetit.rc directives are defined exclusively by a superuser, while commands to Bluetit by a client may come from any user in the airvpn group. In this way the superuser may optionally limit what airvpn group users can do with the firewall and the network settings of the machine, enforce connections only to a certain set of servers, forbid traffic outside the tunnel in any case, and so on. Kind regards

@crypto1.0 Hello! Yes, ufw is a firewall frontend which sets its own customized chains with several rules, It may cause block of incoming packets and potentially it might interfere with Network Lock. ufw may be configured differently in different distributions and distribution versions.. We're glad to know that you managed to resolve the problem. Kind regards