Staff

@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

If you youtube 'Christian Mcdonald', he explains everything in his series of videos. He's also overseeing the wireguard package for netgate, and talks about the whole process and where he wants to take it in the future. Hello! Speaking of netgate.com, we found this article on it which looks good: https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-client.html In order to fit it to AirVPN, please generate a configuration file for WireGuard and the server or country you wish from the Configuration Generator. It's a text file inside which you can find the settings/values you need. Kind regards

@OpenSourcerer @tudou Hello! We have resolved the problem. Kind regards

Thank you for your great feedback and the head up. Lists should have been updated every 24 hours but the procedure started failing recently. We are working on it to detect the problem and restore the normal update every 24 hours. EDIT: problem detected and fixed. Kind regards

@cheapsheep @eburom @magnavoid @OpenSourcerer Thank you very much for the bug report, the issue will be investigated very soon. In the meantime please force nftables (if available, and remember that userspace utility nft is currently required) as @cheapsheep suggested to circumvent the problem. EDIT: Eddie, Hummingbird and Bluetit assume that iptable_* modules exist if iptables exists. This is no more true in some distributions, where iptables userland utility exists but iptable modules don't (and it would be false even in customized kernels compiled with embedded iptable). We will be working on a more robust implementation. @eburom Both implementations are logical and probably the "Right and Just" one does not exist. If Bluetit renounced to the connection when Network Lock fails it would leave the machine completely exposed (remember that Bluetit is a daemon) because it has no way to block the traffic when the firewall fails (*). If Bluetit goes on at least it tries to connect the machine and establish a "tunnel". In early Bluetit implementations Bluetit aborted the connection if Network Lock failed, now the other solution has been preferred even after consultation with users. (*) It might sabotage the routing table or the gateway or it might turn off the network interfaces to isolate the machine completely, but this solution is considered too invasive and it is unacceptable for various system administrators, especially those who run remote servers. Kind regards

@chimney sweep Hello! Understood, we are investigating, there's no need that you keep posting. Kind regards

@chimney sweep Hello! Feel free to specify the server. To forward an inbound port to a specific node, a server applies prerouting rules created (according to customer's settings), transmitted and ordered by our backends to the VPN server. Failure of rules enforcement only on one server hints to a problem of some kind related to that server, and by telling us the specific server you experience the problem on you help us troubleshoot those cases which are not detected by the automatic supervision and warnng system. Kind regards

@JamesFrancis Hello! Please try connections to specific Swiss servers and note whether you can connect to some of them. We operate different datacenters in Swiss so it seems impossible that they have the same problem at the same time. However, when you use the FQDN ch3.vpn.airdns.org, you end up to a specific server which the system reputes "the best in Swiss", therefore checking single servers one by one is essential to understand the nature of the problem. Then, please send us the list of servers you can't connect to and a log showing the connection failure. Kind regards

Hi, that's true. Perhaps the most practical solution is entering a transitional state by leaving some forum dedicated section still to Invision and rewriting (when the license allows it) some critical parts we don't like of those sections, while other important parts and pages will be completely detached from Invision. Then, in a farther future, eliminate the remaining Invision parts one by one. Kind regards