Staff

@niecoinny @OpenSourcerer Some info that might come handy for the current discussion as well as for future reference (Linux only). Various systemd versions currently used in the majority of Linux distributions, are affected by a severe bug. When the bug comes out, at the proper termination of a unit, systemd sends SIGTERM immediately followed by two SIGKILL signals, without respecting the timeout. The bug affects at least the following versions: 204, 215, 234, 246, 248 therefore most (all?) Linux-systemd distributions are involved. When the bug comes out (frequently in 204 and 215, sometimes in 234, very frequently/always in 246, under investigation in 248) Eddie can't restore DNS settings and firewall rules (of course), and the same will happen with Bluetit (a real daemon included in the AirVPN Suite). Next unit files for Bluetit will include the only known (so far) workaround for this problem, i.e. directive SendSIGKILL=no. You can find hundreds of web pages reporting the bug in details in years, in the bug tracker too, but unfortunately a definitive fix has not yet come out. Example which summarizes well the problem: https://groups.google.com/g/weewx-user/c/Yg8OJ7uot7U @niecoinny It's worth testing AirVPN Suite in Linux, if you have time. We're also very glad to know that you managed to run Eddie properly with runit after some effort In this case, the various problems caused by systemd should vanish. On the other hand, while Eddie remains a system process, Bluetit is a real daemon. Out of the box the installer supports systemd and various SysVInit-like systems, but it's untested in your specific environment, so let us know whether you decide to test it (if so, go directly with 1.1.0 RC 4 - 1.1.0 release is imminent). Even if your init system can't be handled by the installer, you can treat Bluetit according to your needs easily. Since it is a real daemon it should be possible to handle it classically in most init systems with no peculiar problem. https://airvpn.org/forums/topic/49247-linux-airvpn-suite-110-beta-available/ Are you running runit as a supervisor of some SysVinit-like system or are you using it as a total drop-in replacement for init? Your decision to avoid systemd is in our opinion very wise. systemd is much appreciated by many people coming from Windows because it replicates some Windows concepts but betrays the basic UNIX philosophy and never you have seen such a monstrosity in, for example, the vastly superior FreeBSD (where, instead, you can find even runit). And yes, with runit you should achieve under many circumstances (bootstrap for example) higher performance than with systemd and you remain safe from the interference at many system levels of systemd (which is not only an init system). Keep us posted if you test! Kind regards

@967819f75c Hello! No, they expire only when you revoke (or "renew") them. As you prefer. Anyway, it's not "key-value", it's a client certificate and a client key It's a unique client certificate and a unique client key (in the sense that they are unique to each client). They are a fundamental part of the authentication phase between a client and our servers. Each account can have multiple client certificates and keys for comfort and to connect multiple devices to the same OpenVPN process at the same time. As you prefer. The ticketing system is essential to receive support from our support team In the forum you get answers from the community and occasionally from some staff member (the "community" forums are by the community for the community, and staff members interfere only occasionally). The support team can be more effective and potentially more competent than a single staff member and sometimes it can find solutions that the community or some staff member missed. In 11 years AirVPN never outsourced customer care, so you can rely on personnel that works directly for AirVPN (someone since 2010!) and you can be sure that you're not sending information to third party generic support teams / call centers etc. Glad to know it. Thank you, enjoy AirVPN! Kind regards

Hello! You don't have different usernames and/or passwords. Credentials for web site and VPN infrastructure access are exactly the same. What you report is indeed unexpected because the very same base table is queried when an account logs in to the web site or via Eddie or Bluetit. Anything else simply does not exist. To log successfully you can enter either username or linked e-mail address (if any). EDIT: if you had some special character outside UTF-8 in your password, that might have been the reason. Eddie and the bootstrap server expect UTF-8. If in doubt about UTF-8 and ISO-xxxx-x encoding tables, rely on ASCII only. That could have been a different reason. For example, access to the infrastructure does not imply access to VPN servers if the client certificate and key pair has expired (maybe you revoked or renewed)? Check here: https://airvpn.org/forums/topic/26209-how-to-manage-client-certificatekey-pairs/ Complete system report by Eddie might help us clarify the issue. Kind regards

@Fly AirVPN But "Obtain a free trial" is quite visible in the "Buy" page and actually we deliver hundreds of free trials per week or so, therefore many people see it. We think that the "Buy" page, which shows plans and payment methods in details, is appropriate to offer free trials and make the home page lighter (it's already a little bit overcrowded). Who thinks that free trials should be advertised on the home page? Let us know. Kind regards

Nope, that prints only the last 18-19 lines in most versions. Insufficient. Nope, that's not supported in various journalctl versions, including the default version in openSUSE 15.2 (latest release) and many other distributions. Nope, that requires persistent journal. Disabled by default in many, maybe most, distributions. Nope, that's very rudimentary re-direction in bash and other interpreters. Bash functions are a totally different thing. If you think that a rudimentary re-direction is an "absurd shell function", maybe UNIX shells are not for you. Try Windows PowerShell. <evil grin> Kind regards

Hello! Nope, there's a big difference, at least for customer support personnel. 😀 journalctl -u option by default will force the user to press <SPACE> etc. to reach the end of the log or "q" to exit prematurely or the <END> key cutting out parts of the log. Any combo of the above has translated (and will again translate sooner or later) into users sending us only pieces of log. We could ask the user to re-direct the output to a file, then find the file, print it or open it with a text viewer, copy and paste its content on the next msg but why? It is additional work that's not really needed. We can save anyway piping and make you happier with < <(sudo journalctl) grep bluetit It seems that @bulbous_blues is in a subnet inside 192.168.0.0/16 which Bluetit always sets completely open in input and output, both with iptables[-legacy} and nftables. Can you confirm @bulbous_blues ? Kind regards

@bulbous_blues Hello! Bluetit can't interfere and should not be responsible of the issue you report. In bluetit.rc file, the following line is wrong: airport 37845, 8002 because only one port must be provided and because none of those ports are valid. Our OpenVPN processes listen to ports 53, 80, 443, 1194, 2018. In this case you might not notice the error because "airport" directive is ignored when connection mode is set to "quick" (NOTE: this feature changes in Suite 1.1.0). Anyway feel free to send us Bluetit log: sudo journalctl | grep bluetit Kind regards

@colorman Hello! We have discovered some other bugs (while we fixed the ones you reported) which caused network recovery failure. A new version is coming, probably on Monday. Kind regards

@OpenSourcerer Hello! It must be seen how nm-ovpn handles DNS push. Historically, it has always been able to properly accept DNS push and then restore previous settings at the end of the connection. However, a double-check in those systems which run systemd-resolved configured in on-link mode and /etc/resolv.conf bypass (example: Fedora 33 by default settings) would be safer, you never know. In other systems where the global DNS is preserved and nameservers are "decided" by /etc/resolv.conf it appears that nm-ovpn properly handles DNS push, no DNS leaks are possible. A more general approach when you don't know which configuration you might encounter is (on top of usual network lock rules) blocking, via firewall, packets (both TCP and UDP) to port 53 of the router address, to prevent that local queries can be forwarded by the router in clear text to some other nameserver, potentially the ISP DNS server (it would not be a DNS leak, because the system does what you tell it to do, but the outcome is anyway a query out of the tunnel). Kind regards

Hello! Well, of course Wireguard is catastrophic in this sense, because it is very poor in options, but luckily it's not the same thing with OpenVPN, because in Wireguard by default you have 1) a permanent bijection between private IP address and client KEY (we will delete the link periodically when we offer Wireguard and re-create it when a connection is required), because Wireguard does not support any other method to dynamically handle clients (this feature might be implemented in the future) This dangerous pre-prepared static link does not exist at all in OpenVPN. 2) your real IP address is permanently stored by Wireguard even after you turn off your software or machine, because Wireguard is extremely limited and does not have any explicit-exit-notify or ping-timeout option (we will therefore force deletion and disconnections after some time there is no communications by the clients, even though this will cause some unexpected disconnections). OpenVPN does not need to do so because it realizes when one of the peers is no more there, even in UDP of course, so the real IP address for the socket etc. is immediately lost at disconnection. 3) Wireguard requires that the mentioned data is stored in files (we will keep them in RAM as usual, to mitigate the problem) But yes, we will re-consider the whole matter, just in case. Additional re-checks in security fields are always good Kind regards

Hello! This happens by explicit configuration server side. We opted for this solution because we received a large amount of requests to do so. It makes binding of specific processes which can bind only to IP addresses and not to interfaces (from inner settings) so much easier. This configuration can be changed (try Xuange server for example) but currently it will be not, because the requests to do so have been very many. Anyway this is unrelated to AirVPN Suite testing so we will split the messages to a different thread in Suggestions, therefore any user can write what he or she prefers. Kind regards

Hello and thank you! You will be able to get the special prices even during the first days of June. Kind regards

@Stalinium Hello! Maybe you talk about network-manager-openvpn plugin, as network-manager by itself does not support OpenVPN. In our configuration files the directives to cause IPv6 push are included, unless you specifically tell the CG to NOT route IPv6 over IPv4. It's not our fault if they are ignored. On the other hand we have been deprecating usage of network-manager-openvpn since years and years ago for other critical problems. If you decide to use it in spite of our recommendations, you do it at your own risk. You are not forced to run our software in Linux. You can run OpenVPN directly for example, or any other OpenVPN GUI/wrapper different than network-manager-openvpn. In this case, you will of course need by yourself to take care of DNS push and network lock, features that are handled automatically by all of our software for Linux. It's therefore a security issue by network-manager-openvpn, not by AirVPN, because it's network-manager-openvpn that ignores directives that our Configuration Generator puts in, and it's you the one who does not replicate Network Lock which would have made the problem anyway irrelevant (under a security point of view). Nonsense, a MAC address is simply is not included in IPv4 packets (there's just no room for it), while nowadays all systems mitigate the MAC problem in IPv6 addresses. Our servers never receive the MAC address of any of your physical network interfaces of the router and even less of the computer. The problem is more basic, and it's simply having IPv6 traffic outside the VPN tunnel but keep in mind that you ignored instructions and our suggestions, up to the point to use exactly the software we tell you NOT to use. About FBI... What FBI really did was something quite different and is not a Tor problem in itself (for Silk Road, for example, it was "only" social engineering, by infiltrating an agent in the core of Silk Road and exploiting administrator's trust in this infiltrated agent - in other cases it used javascript which the final user recklessly allowed execution of, on the browser, and in a Windows system) but anyway they are talking about Tor and not OpenVPN, so we can cut the FBI cracking techniques discussion here as it is irrelevant for the matter. Unfortunately not all OpenVPN versions, in client mode, can push a UV, and most versions which can't are the old ones which are also bugged with IPv6. The whole setup has been made with the purpose not to send IPv6 push to those OpenVPN versions which are bugged and would create critical errors with IPv6 push. This backward compatibility may be abandoned one day, but it's still not the right time. Anyone having new versions can send UV and therefore this solution makes everyone happy. Furthermore our Network Lock includes IPv6 rules to prevent leaks. Remember that VPN software is not designed to provide an anonymity layer. It's the environment we create with our software which makes it possible, and VPN connection is a part of the anonymity layer. If you renounce to part of this environment by not using our software, you must understand what you do and how to replicate various features, first and foremost Network Lock. If you use a software that, to make things even worse, negligently ignores our own CG directives, and it is furthermore deprecated by us, then you're running at your own risk, ça va sans dire. . Kind regards

Hello! Today we're starting AirVPN eleventh birthday celebrations offering special discounts on longer term plans. It seems like it was only yesterday that we celebrated the 10th milestone birthday, and here we are, one year later already. From a two servers service located in a single country providing a handful of Mbit/s, the baby has grown up to a wide infrastructure in 22 countries in four continents, providing now 240,000+ Mbit/s to tens of thousands of people around the world. We still define it as a "baby", but AirVPN is now the oldest VPN in the market which never changed ownership, and it's one of the last that still puts ethics well over profit, a philosophy which has been rewarded by customers and users. 2020 (and 2021 so far) have been harsh years for the mankind but we have no rights to complain too much because AirVPN was only marginally touched by those terrible repercussions which affected many other business sectors in general. In spite of that, we could not maintain our promise to deliver native software for FreeBSD and we apologize for the failure. However, releasing software for FreeBSD, specifically AirVPN Suite, remains one of our goals, so stay tuned. On the other hand, Eddie desktop edition, AirVPN Suite for Linux, Hummingbird for Linux and macOS, and OpenVPN 3 AirVPN library were updated substantially and swiftly. Moreover, Eddie Android edition development has been recently re-opened to provide a new version updated to new requirements and specifications of Android 11 during 2021. Hummingbird was natively released for M1 based Apple Mac systems too, allowing a dramatic performance boost (up to +100% in >100 Mbit/s lines). Behind the scenes, infrastructure had some paramount improvements. The whole network in the Netherlands has been enlarged with additional redundancy and several servers around the world have had hardware upgrades. In Sweden and Switzerland we started operating servers connected to exclusive 10 Gbit/s lines and ports, and we optimized the environment to obtain more bandwidth from the OpenVPN processes. We managed to beat the previous 1.7 Gbit/s barrier. The performance on the customer side has improved and reached new peaks of excellence, as you can see here: https://airvpn.org/forums/topic/48234-speedtest-comparison/?do=findComment&comment=130191 Furthermore, the infrastructure has become fully Wireguard capable and throughout 2021 we will start offering Wireguard connections, in addition to OpenVPN ones, in an hardened environment which mitigates the numerous privacy problems posed by Wireguard. Last but not least we re-started operations in a fourth continent, Oceania, with a new server in New Zealand. All AirVPN applications and libraries are free and open source software released under GPLv3. It's worth quoting literally what we wrote last year for AirVPN birthday: Kind regards and datalove AirVPN Staff

@WilDieteren Hello! Backend is already running natively. Frontend still needs Rosetta 2 because Mono does not exist yet for M1. Anyway frontend does not have any time critical duty, so it's not a big deal. The real deal is OpenVPN 2/OpenSSL which is still slow in M1 (just like it is slow on Intel Mac anyway) so you might like to have Eddie run Hummingbird for M1, or run Hummingbird for M1 directly. If you have more than 100 Mbit/s, you should get around 100% boost. Kind regards

@SeUbHS Hello! Yes, set your blocking rules as default rules while Eddie is not running and has just exited cleanly. Remember to allow local network, and special destinations such as 255.255.255.255 in order not to block DHCP (at bootstrap etc.). Since you run iptables you can simply enforce DROP policy to the OUTPUT and INPUT chains of the filter table, and then set a few rules jumping to ACCEPT for local subnet, localhost and 255.255.255.255. A very simple startup script (it's only an example, you must modify it according to your needs and the features of your network, and you can also use iptables-save to make rules permanent - also specify the correct path to iptables): iptables -F iptables -P OUTPUT DROP iptables -P INPUT DROP iptables -P FORWARD ACCEPT iptables -I INPUT -s 255.255.255.255 -j ACCEPT iptables -I OUTPUT -d 255.255.255.255 -j ACCEPT iptables -I OUTPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT iptables -I INPUT -s 192.168.0.0/16 -d 192.168.0.0/16 -j ACCEPT iptables -I INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT iptables -I OUTPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT When Eddie enables Network Lock, you can communicate with AirVPN infrastructure only. When Eddie disables Network Lock (including when it quits) it will restore your blocking rule, so your machine will be isolated from the Internet. Kind regards

Hello! If you confirm that the sentence is correct ("when Eddie ISN'T running") then yes, it may be normal behavior. When Eddie is properly closed, it de-activates Network Lock. However, if Eddie isn't running because it crashed, then Network Lock remains enabled, because it's a set of firewall rules which are not modified. Kind regards

@183aTr78f9o Hello! Quite right. The feature will be available in the 1.1.0 stable release. Kind regards

@khuffmanjr Hello! Can you send us both output of Eddie when you stop it by pressing CTRL-C in the shell and when you stop it will kill -SIGTERM ... ? Kind regards

Hello! Same error code, same explanation, but in this case the cause should lie in the behavior of the machine during sleep and at wakeup. To save time, try to reset network and re-start Eddie, it might be enough and would save a reboot. Kind regards

@tronchilwelch Hello! To delete an imported profile, please go to the "Profiles" view, long-tap a profile then select "Delete" from the contextual menu. The "default" profile is the last one you have picked. It will be used even for the connection at boot, if you halted the systems while Eddie was connected through a profile and the option to connect at boot is on. Kind regards

@colorman Hello! We finally managed to understand how to reproduce the issue. We are working on it. In the meantime you should be able to circumvent the problem in any of the following ways. Please check if you have time. specify your network lock favorite method via networklock or networklockpersist directive in file /etc/airvpn/bluetit.rc - then you don't need to specify it on goldcrest command line. You can edit, with root privileges, /etc/airvpn/bluetit.rc with any text editor (example sudo nano /etc/airvpn/bluetit.rc). Enter anywhere the line networklock on, or even networklockpersist on then save the file alternatively, connect without a profile, for example goldcrest --network-lock on --air-connect -air country <your favorite country> (you may enter your AirVPN credentials on the terminal when Goldcrest asks for them, or set them in Goldcrest configuration file) Kind regards

@colorman Hello! We are struggling to reproduce the issue, openSUSE 15.2 is one of our testing systems for AirVPN Suite and we fail to understand why we can't get the same behavior you experience. We have tested both with firewalld enabled and disabled, both with iptables-legacy and nft 0.8.2 (all combinations) and everything went smoothly. In other words, network lock is engaged and disengaged correctly, either with iptables-legacy or nft, tested both with firewalld running and not running. Can you please try again network lock with: - firewalld disabled (not running at all) - by enforcing iptables-legacy (networklock or networklockpersist set to iptables) - then, by enforcing nftables (networklock or networklockpersist set to nftables) We are looking forward to hearing from you. Kind regards

@183aTr78f9o Hello! You can find an explanation and the immediate solution for you needs, which takes just a few seconds, in our previous message.. In this way you can have network lock even when you press a hard reset button or you power cycle the machine while it's working at your own risk.. The fact is that a daemon must never perform root operations if the lock file exists Ignoring this simple but important rule would be terrible, for quite obvious reasons. Never mind if you can't understand why right now: remove the lock file and you will have the behavior you want. If you read the whole documentation there should be no misunderstanding. What it matters is underlining that Bluetit is so flexible that even in this case you can achieve your purpose simply, in the way we described. Sure, if it suits your needs why not. Just remember that Hummingbird is not a daemon and keep in mind the architectural difference, to understand the risks. No reason to be sorry, you were never asked to in the first place. Those questions were rhetorical ones to clarify that in our opinion Bluetit should not take into account all the possible combinations and try to enlarge its scope, because that's strictly a matter of other system components. Given the non-uniformity in behavior of hundreds of Linux distributions, and their ever changing and evolving behavior, we believe it's a wise choice not to interfere in other processes duty. Therefore, we can close the issue, the behavior is correct and expected, no bugs here. Kind regards

@colorman Hello! We see that you get some error even when Bluetit enforces network lock through iptables-legacy. However, from the log it's unclear whether those errors are irrelevant or not. While Bluetit is still connected with network lock on (with iptables-legacy, as it is in your last log you sent us) can you send us the output of the command iptables-save ? About nft 0.8.2, it's an obsolete version. However, Bluetit now handles it correctly (tested in Debian 9 and openSUSE 15.2) - let's see first iptables-legacy anyway. Kind regards