Jump to content
Not connected, Your IP: 3.229.142.91

Staff

Staff
  • Content Count

    9130
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1351

Everything posted by Staff

  1. 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
  2. @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
  3. @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
  4. @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
  5. 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
  6. 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
  7. Hello and thank you! You will be able to get the special prices even during the first days of June. Kind regards
  8. @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
  9. 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
  10. @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
  11. @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
  12. 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
  13. @183aTr78f9o Hello! Quite right. The feature will be available in the 1.1.0 stable release. Kind regards
  14. @183aTr78f9o Hello! It's expected. You get "D-Bus service org.airvpn.server is not available" because Bluetit is not running, and Bluetit is not running because when it finds the lock file when it starts, it immediately exits, as it must do. Since this Bluetit behavior is totally correct, we are splitting these last messages to another thread in "Troubleshooting and problems" forum to keep the original thread focused on testing Suite 1.1.0 RC. Kind regards
  15. @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
  16. 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
  17. @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
  18. @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
  19. @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
  20. @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
  21. @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
  22. @183aTr78f9o Hello! Behavior 1 is expected: when you enforce a savage reboot by pressing the hardware button, bluetit.lock fie in /etc/airvpn is not deleted (not even by intrusive systemd, as it happens normally), so Bluetit needs to exit at the next run, necessarily: another instance might be running - and anyway the anomalous situation must be investigated by root. If you want to force Bluetit start in any case without verifications, you just need to delete /etc/airvpn/bliuetit.lock first if it exists (re) start Bluetit finally run goldcrest --recover-network In this way Bluetit will start in any case. Then, if it finds a dirty situation for the DNS and firewall backup files, it will remain running (it would exit only if the lock files existed): then Goldcrest will ask Bluetit to recover network, Bluetit will comply (if it's in a clean situation it will simply ignore the network recovery order) and immediately after will activate network lock (if newtorklockpersist is specified) and also connect if connectatboot <mode> is specified. Remember, therefore, not to postpone Bluetit (re)start command with goldcrest --recover-network command, otherwise Golcrest will find no service to contact via D-Bus in your context. Issue 2 is related to how a system handles suspend/resume: is the network interface powered off? If so, at resume is network re-initialized? If network interface kept working, is network initialized anyway, or do we still have the routing table set by the VPN client according to the server push? What about firewall rules and tun status? We leave the behavior to each system, ideally Bluetit should not take care of all the possible combinations. Your proposed solution is fine, if we come out with something better we will let you know. A possible weakness of your solution is that the "wake up" unit you defined might start BEFORE Bluetit runs, in some anomalous situation. Thank you very much for your tests! Kind regards
  23. @John Gow Hello! It looks like more a "picking the right server for you" problem than an overload or load balancing problem. We also don't see any overload in US or CA West Coast. Can you define a while list of your favorite servers? It should meet your needs. You can define the list in Eddie's "Preferences" > "Servers" window. Multiple selection (CTRL + click and SHIFT + click) is allowed for your comfort. Once a white list is defined, Eddie will consider only servers in that white list. Kind regards
  24. Hello! @colorman Goldcrest invocation appears correct. The full Bluetit log might be more helpful, can you please publish it? Also, can you tell us your nft version (command "nft --version")? @183aTr78f9o The 1st reported behavior is expected. because Bluetit must not proceed when it is in a "dirty condition", but it remains to be seen why Bluetit did not exit cleanly in its last session. Was it intended as a test (i.e. you explicitly wanted a dirty startup to test), or is it unexpected? (OK, you already wrote it was a test ). Once you have issued goldcrest --recover-network you don't need to restart Bluetit, you can directly start a connection. Also, Bluetit will activate network lock immediately after a network recovery, if networklockpersist is set in bluetit.rc - another good reason to avoid a restart. The 2nd remark describes an unexpected event. What happens after you resume the system? Can you send us the full Bluetit log taken just after the problem has occurred? The expected behavior would be that Bluetit daemon does not exit at all, in the first place, when you order an hibernation. Let's see what kills it, if possible. @leori Thank you, we're very glad to know it! @air2157 We're glad to know that Hummingbird launch by Eddie is fine again. As explained, up and down scripts with script-security 2 enlarge attack surface and we think that it's very appropriate that a library and a root process (Hummingbird) do not offer them. Even in Eddie, script-security, up and down custom directives have been forbidden a long ago for critical security reasons. Furthermore Eddie does not even allow you to use an arbitrary external ovpn profile, and we're considering to stop supporting it in Goldcrest/Bluetit too. About the documentation: please note that, just like it happens with any documentation, we document implemented features, not unimplemented ones. Bluetit developer's documentation is also on its way and we plan to publish it immediately after AirVPN Suite 1.1.0 stable has been released. As you know we have forked OpenVPN3 so we don't need to wait for bug fixes from the main branch if they are too slow to come or they are urgent. The parts which were not ready for production in our tests have been fixed and/or rewritten already, as these last 3 years of releases and testing in different systems should have shown. In any case, please feel free to point us to those source code parts that you deem as not ready for production at your convenience. Thank you for your previous tests, they have been much appreciated. Kind regards
  25. Hello! We're glad to inform you that AirVPN Suite 1.1.0 RC 4 is now available. Download URLs have been updated accordingly in this thread first message. Please check the changelog for a full list of important changes, which in this last time frame between RC3 and RC4 have been particularly numerous. The latest problems found by our internal and public testers have been reproduced and addressed. Thank you all, you brought to light various, elusive bugs which slipped unnoticed through all the previous testing phases. AirVPN Suite 1.1.0 RC 4 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. OpenVPN AirVPN 3.7 is now 103 commits ahead of the main branch, featuring several, new important features and very many bug fixes. https://github.com/AirVPN/openvpn3-airvpn Please keep testing RC 4! Kind regards AirVPN Staff
×
×
  • Create New...