Staff

Hello! Of course. Not only OpenVPN-AirVPN code is clean, clearly commented and can be maintained efficiently (Donald Knuth is an ideal master of the AirVPN suite developer chief ) but we also submitted pull requests initially for the master branch, before we forked.. An OVPN3 project leader and some other person reminded us that pull requests could not be accepted if AirVPN did not disclose the real identity of its developers, and if AirVPN did not accept the re-licensing clause specified in the CLA.rst contract stating that OpenVPN Inc., and only OpenVPN Inc., can re-license our code under any other license, including "non open" licenses (Part, II, https://github.com/OpenVPN/openvpn3/blob/master/CLA.rst) Both conditions were and are not accepted by AirVPN, and we were forced to fork. Therefore, upstream must be performed by third-parties or by OpenVPN Inc. itself, but remember that we do not agree to the mentioned contract, especially in the part which states that code may be re-licensed by OpenVPN Inc. under any other license. Currently, the following modifications by AirVPN can be of particular interest for the main branch: the (N_)RECONNECT bug fix in Linux the data channel cipher selection bug fix the new implementation of Data Channel cipher negotiation compatible with OpenVPN 2.5 new method as well as the older OpenVPN 2 implementation the "ncp-disable" directive implementation (it comes handy with older than OpenVPN 2.5 servers) the "data-ciphers" directive implementation the fix of the "explosion" bug triggered under apparently random circumstances, in reality due to the unbelievable lack of data structure initialization in at least five different parts of the code the cleaner rewrite of the options parser getting rid of a good amount of parsing bugs the new method to select the correct cipher for each packet with pointer to methods in place of a dumb, and slower, series of "if" in the main branch which are executed at every and each outgoing or incoming packet block (useful when it's linked against mbedTLS) many other bug fixes which would make this message too long for this thread - being 103 commits ahead, you really have a more stable, more OpenVPN 2 compatible, and faster library now Kind regards

Hello! Acknowledged. The documentation is not only online, it's included in the package too so you can consult it anytime, even if you're offline. Kind regards

@air2157 Hello! We think you're right. If confirmed, it does not seem as an Hummingbird limitation at all: we must check twice but at a first glance we have dragged such a limitation from the main branch of OpenVPN 3 library, specifically here: https://github.com/OpenVPN/openvpn3/blob/master/openvpn/options/merge.hpp when OpenVPN3 wants to merge additional profile (about which, we will have some questions for you after some tests, stay tuned ). We have already widely rewritten critical OpenVPN 3 parts in our fork, fixed dozens of bugs and conceptually wrong code, added new key features and essential directives, and we will rewrite even this part if it comes out that it's a counter-productive implementation by the main branch developers that we missed. Again, we will not hesitate to rewrite other code whenever the main branch code is inappropriate, after we have consulted with the development leader, as we have always done. Thank you for having found out the issue and reported it to us. @OpenSourcerer In this case the documentation is correct, as Hummingbird does not enforce limitation on the file name. Work on Hummingbird documentation has received excellent feedback (dozens of positive comments), readers please check here: https://airvpn.org/suite/readme/ https://airvpn.org/hummingbird/readme/ However, and obviously, anything can be improved. Is there anybody else here who can give us an additional feedback about Hummingbird & Suite documentation? OpenVPN3 main branch is undocumented while its source code is poorly commented, so it may have happened that a peculiar feature, especially when it is as "strange" as it seems in this case, has been missed. Luckily, nothing that justifies the "sloppy" adjective, in our opinion. Remember that we offer a README.md specific to HB which is much more complete than a man page (you can't of course stuff the whole readme.md in the man pages). man pages had been planned for the AirVPN Suite and not for Hummingbird, since Hummingbird had been considered a binary which can be launched by Eddie, while as a stand alone binary it was just transitional software to show what our AirVPN OpenVPN 3 library could do, before we had a real daemon, Bluetit, whose version 1.1.0 release has now the priority. Of course now that Hummingbird appears to have reached such a wide appreciation and success (which we did not expect) we may change our plans, in order to maintain Hummingbird not only as an Eddie alternative to OpenVPN (Hummingbird in Intel Mac and in M1 Mac provides a 2x throughput boost against OpenVPN 2.5), but also as a part of the Suite. Next step is publishing the developer's manual for Bluetit, our first and only real daemon, which we deem as very important. Then we can consider man pages specific to the Suite and in that occasion we can re-think about Hummingbird man pages, because at the of the day we offer a much more complete documentation than a man page. We totally agree with you. If the restriction is confirmed OpenVPN3 main branch developers might be asked about why they think it is appropriate to enforce it, anyway we have seen worse things in the original source code. On our side, we will verify the problem and we will remove it if confirmed, luckily we forked OpenVPN 3 a long ago so we have no constraints. Our fork is now 103 commits ahead the main branch, and we assure you that we are determined to wipe out any other OpenVPN3 main branch "absurdity", according to your definition, we find. Kind regards

@lostagain Hello! Trivially because when your system is in the virtual network, it is also in the real network provided by your ISP. You will not receive unsolicited packets from the VPN if you don't forward ports remotely, but you can still receive them from your ISP network. Network Lock will block those incoming packets but that will not prevent a DDoS of course . A better solution is that you do not forward packets from your router to your systems when your systems are in the VPN. Also remember that if you forward remotely ports, you will be protected by the global anti-DDoS system on the server datacenter, and you will not have specific traffic inspection for your forwarded packets to filter them against attacks. We do not inspect our customer packets by policy and our network remains agnostic. Kind regards

@OpenSourcerer @WinniethePooh Hello! Yes, that 50.x.y.z is an address of one of our micro-routing servers. Certainly Binance must have been "micro-routed" for some anti-blocking purpose after customers' requests. This information should clarify and resolve the "enigma". Kind regards

@pjnsmb Hello! gb3.ipv6.vpn.airdns.org is updated correctly, so Bluetit will connect to the correct server that domain resolves into. The failure to resolve names during Bluetit start at bootstrap but the ability to do so afterwards remains a problem which we could not reproduce so far. It was detected in Raspbian and OSMC, due to their settings which cause systemd to run Bluetit prematurely, and fixed by implementing in Bluetit its own network link detection. Kind regards

@pjnsmb Hello! It has been sorted out, please try again now (for the readers: anyway not a Bluetit issue). Kind regards

@colorman Hello! Another piece of info please. When you run Hummingbird (and it "explodes"), do you have Bluetit daemon running as well? Kind regards

@colorman Good! Now network lock works with Goldcrest/Bluetit, when you force nftables. Momentarily, do not forget to force it, otherwise network lock will fail. We will be investigating on this bad issue. Correction: it does not work with nftables as well. About Hummingbird, thank you: we see that Hummingbird crashes when it is invoked in that way, as Eddie does, so we have now a track to understand what happens. We'll investigate on it as well, of course. Kind regards

@colorman Typo (now fixed, please fix it yourself too). Enter: sudo hummingbird --network-lock off --ignore-dns-push foo.ovpn Remember to specify the full path to the *.ovpn file if necessary. Kind regards

@colorman That's expected, Goldcrest parser expects the configuration file at the end of the whole command, so it assumes that "nftables" is the configuration file. Retry with: ./goldcrest --network-lock nftables AirVPN_Netherlands_UDP-443-Entry3.ovpn Remember to specify the full path to *.ovpn file if necessary. Kind regards

Hello! Please generate a configuration file form the Configuration Generator (in your account "Client Area", in our web site) with the same protocol, port, destination server that cause the problem with Eddie+Hummingbird. Then run Hummingbird as Eddie does: sudo hummingbird --network-lock off --ignore-dns-push foo.ovpn where foo.ovpn must be replaced by the full path and name of the ovpn configuration file you previously generated. The options to disable network lock and reject DNS push are included to run Hummingbird in the same way Eddie does. In this way we should be able to see what happens to Hummingbird and maybe have some clue. Kind regards

@colorman Hello! Can you please also test Bluetit with nftables (which should be the default filtering platform in your openSUSE version)? First, you need to install nft (it's a binary utility run by Bluetit as a frontend to nf_tables packet filter), if it's not already available in your system. Then, just run Goldcrest as you usually do, but with the following, additional option: --network-lock nftables Check whether you still get an error, in Bluetit and Goldcrest logs, about network lock or not. Kind regards

Hello! The "disconnecting" log entry comes from Eddie and it seems that Eddie does not receive any other log entry from Hummingbird justifying the disconnection. Is such an unexpected behavior experienced by your system even with older Hummingbird 1.1.0? If you run Hummingbird 1.1.0 RC 3 on its own (without Eddie) with the same configuration file generated by Eddie, what do you see? Kind regards

@colorman Hello! Thanks! Can you please print all iptables-legacy rules while the connection is still active? Please enter command (from another shell) iptables-legacy-save, then copy all and paste here, thanks! Is this error occurring all the times, or occasionally? Does the error persist if you stop firewalld? Did you notice this error in some past 1.1.0 beta or RC version? Kind regards

@colorman Hello! Thank you for your tests once again. As usual, can you please send us the complete Bluetit log (output of the command sudo journalctl | grep bluetit) printed after the problem has occurred? Can you also tell us the current system firewall when the problem occurs? Kind regards

Hello! We're glad to inform you that AirVPN Suite 1.1.0 RC 3 is now available. Download URLs have been updated in this thread first message. AirVPN Suite 1.1.0 RC 3 aims at addressing RC 2 Bluetit problem or regression suffered in D-Bus message handling and found out (unfortunately not reproduced on our systems) by our community testers @pjnsmb @leori and @colorman Please keep testing RC 3! Version 1.1.0 RC 3 - 16 April 2021 - changelog [ProMIND] Updated to OpenVPN 3.7 AirVPN [ProMIND] vpnclient.hpp: avoid netFilter setup in case NetFilter object is not private [ProMIND] dbusconnector.cpp: fine tuned D-Bus wait cycle in R/W dispatch. Implemented a thread safe wait in order to avoid D-Bus timeout policy Kind regards

Hello! We're glad to inform you that AirVPN Suite 1.1.0 RC 2 is now available. Diownload URLs have been updated accordingly in this thread first message. AirVPN Suite 1.1.0 RC 2 includes NEW OpenVPN AirVPN library 3.7 fixing a couple of issues coming from the main branch causing the library to crash under the conditions found by our community testers and reported in this thread: thank you all! Another issue in the library was the confusion between "proto tcp-client" and "proto tcp" in OpeNVPN 3 main branch, which caused a critical problem as reported in this thread by testers. The issue has been addressed. OpenVPN AirVPN 3.7 is now 100 commits ahead of the main branch, featuring several, new important features and very many bug fixes. https://github.com/AirVPN/openvpn3-airvpn A small change in Bluetit will also cause less CPU usage, at the price of a slightly lower responsiveness (which will not be seen by the naked eye). The main load was caused by the handling of the D-Bus message queue, which is critical because D-Bus does not have a message buffer: if the listener loses a message that message will be lost for good. Through an appropriate fine tuning, now Bluetit will not lose any message but at the same time will need less CPU time. Thanks again to our community testers for having reported the matter in this thread. Please keep testing RC 2! Kind regards AirVPN Staff

@pjnsmb Hello! Under your conditions, Bluetit resolves gb3.ipv6.vpn.airdns.org. We might have some issue with records update, at least for AAAA, so the problem is not in Bluetit. We are investigating, thank you, it is a useful head up. Kind regards

@jrredho Hello and thank you! We can't reproduce the issue, can you see how Eddie runs Hummingbird in your case? If you tick "Debugging log" option in "Log" window Eddie log verbosity will increase and Eddie should print all the commands it runs. Please check also the profile that Eddie generated, which is then passed to Hummingbird. You can see it by double-clicking the "generated configuration" line in the "Stats" window. Kind regards

@c69c7kfrv48fuJ8Re44C Hello! Exactly. Maybe it's worth pointing out even in this thread that we released highly optimized Hummingbird for Apple M1 machines. If you have more than 100 Mbit/s available, you should see around 100% performance boost when compared against OpenVPN. In the download page: https://airvpn.org/macos/hummingbird/ you can clearly identify the Intel and the M1 version. Kind regards

Thank you very much for your great feedback! Nowadays, several "VPN reviews" must be paid. Since AirVPN has never paid for any review, those reviewers who only publish reviews they are paid for will never mention AirVPN, or they will mention it only to advertise other VPN services they are paid by. We prefer offering an honest service at the best of our abilities and let the market speak by itself, rather than fooling gullible people through fake, paid reviews and other dishonest practices. So far AirVPN has flourished thanks to a correct and honest behavior, which has caused a virtuous word of mouth as well as excellent unbiased reviews, and not thanks to clean and/or shady marketing (even because AirPVN has invested ~0.00 on any classical marketing). So it's very important for us that you frankly express your opinion on the service, anywhere you deem appropriate and whenever you have time and if you want to do so! Thank you! Please note that our moderator removed your link in our forum because it linked to a review of a VPN competitor. That's forbidden. The moderator did not imply that you should not comment or talk about AirVPN anywhere! Also note that we operate these forums for our community, and that moderators are members of the community too: they moderate for passion and without rewards, they do not work for AirVPN and they are not part of Staff or technical support team. Kind regards

@Jamertol Hello! Thank you for your request. We're sorry, at the moment we have no plans to offer dedicated IP addresses. Kind regards

@JonathanZR Thank you for having mentioned the review! We would like to clarify a misleading claim by @OpenSourcerer "Challenge accepted. *BSD. I won. FreeBSD, NetBSD and another BSD related system, Darwin, are supported, by most of our software and support team. You can run AirVPN software in FreeBSD, NetBSD, and macOS recent releases (both Intel and M1 based machines), and you can have competent support for each of those systems. So, the sentence by our moderator might be applied to OpenBSD, and only partially. Even if you can't run our software in OpenBSD, you can anyway run OpenVPN with the configuration files generated by the AirPVN Configuration Generator and connect successfully to any AirVPN server. Finally you can have a fully OpenBSD oriented customer care. Kind regards

@courteousorbit Hello! We're sorry, we do not want that because stunnel is meant (in our service) as a tool to bypass (even, but not only) blocks based on certificate replacement. We need to fool the blocking system making it believe that it can decrypt the flow (actually it can decrypt stunnel tunnel). Then, an OpenVPN tunnel is established inside the stunnel one, and that's where the blocking system is fooled in most cases. Data security and integrity is therefore guaranteed by OpenVPN, not by stunnel. If you need proper stunnel setup, then you do not suffer the aforementioned blocks type, so you can probably bypass completely stunnel and use OpenVPN in TCP and in TLS Crypt mode (maybe to port 443, in order to approximate very closely a TLS driven HTTPS connection). You will have even higher performance, of course. Also consider UDP, if you are not forced to use TCP. Kind regards