Staff

@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

Hello! Very puzzling, please open a ticket because we want to check directly the server rules inside the server while you are connected to that server to discern whether the problem is on the server side. Kind regards

@chimney sweep It's impossible in theory that packet forwarding goes on and off during a session because prerouting rules for a node are changed only at the start and at the end of a session, not during the session itself., there's just no existing code to do that. (*) Some twist comes from WireGuard, due to its inability (by design, intended) to detect the end of a session, but nothing that can't be resolved in a matter of minutes thanks to the enforced pre-assumed timeouts. Do you mean that sometimes you have packet forwarding working, and on another session to the same server you have it not working? If so, you already wrote it in many other messages in this thread. If you run both WireGuard and OpenVPN, do you notice any difference? (*) EDIT: not totally true: if ports are modified by a user from the web site control panel, then the controlling servers send commands to all VPN servers the user has active sessions with in order to alter the rules accordingly. - pj Kind regards

@ciudad Hello! It's not planned at the moment because it's more comfortable for us the current single tls-crypt key. tls-crypt 2 doesn't change anything for the client, while on the server side, in our specific case, it would be useless because we maintain tls-auth for backward compatibility,. Any denial attempt would remain potentially possible via tls-auth, hence we would have a complication for nothing. However when we drop tls-auth (we're afraid not in the near future because of the amount of old OpenVPN versions connecting to our service) then tls-crypt-2 will become attractive indeed.. Kind regards

Hello! @OpenSourcerer and any other Arch user. Slightly Off Topic: if Eddie fails with Arch with kernel 5.15.x and nft (the userspace utility) is installed, please contact us. Eddie gives priority to nftables if it finds nft, so if Network Lock does not work even when nft is available something else might be going on. Please check if you can and if you find any malfunciton even with nft installed send us (in a ticket if possible) Eddie system report showing the failure. Also specify the nft version. Kind regards

Hello! Good solution for Eddie because Eddie doesn't let you pick the firewall framework. With AirVPN Suite, if you prefer the newer kernel, you don' need to downgrade, you can just tell the software to use nftables for Network Lock. And you can do the same with Eddie too. Just install nft and Eddie will prefer nftables, no need to downgrade kernel, and the Network Lock will be fine. Kind regards