Jump to content
Not connected, Your IP: 3.227.247.17

Staff

Staff
  • Content Count

    8775
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1266

Everything posted by Staff

  1. @clebretonfr Thank you very much for your tests and for the great feedback! We are investigating the issue at system start you have reported in our Raspberry systems. The Data Channel ciphers you specify in bluetit.rc are those which are allowed by the daemon, thus they are a set enforced by the superuser. The Goldcrest user can then pick any cipher inside that set. Have you noticed some discrepancy from the expected behavior?  This is a server side problem which we will have to face sooner or later. It is not relevant anyway at this stage. Kind regards
  2. @john roberts Hello and thank you very much for your tests! Because the daemon, Bluetit, is not running.Goldcrest is just a client. We see that you run it with root privileges, therefore you destroy a part of the security model created with the new architecture. Please consider not to do so. There is no special procedure, ideally. Even a brutal reboot is fine and must not create the problem you experience. We are trying to reproduce it in Fedora 33. Can you please tell us exactly what you do to reproduce the problem, including how you shut down the system exactly, step by step? We ask because we failed to reproduce the issue in Fedora 33 even by trying a brutal "reboot" from a root terminal inside a Desktop Manager. That would not work in our case. We want to maintain the lock file because Bluetit must NOT start if its previous exit was abnormal. We are talking about firewall rules, DNS settings and routing tables here, so it is expected that the superuser intervenes manually in such cases, no automatic solution is proposed. The only automatic fix is --recover-network aimed at rescuing previouis firewall rules and DNS settings. Then the superuser must remove manually the lock file after she has ascertained that anything else is fine, for example that no other Bluetit instance is running for real. Yes, we will clarify it in the next documentation version. Also remember that Goldcrest can NOT do --recover-network or anything else, when Bluetit is not running. We are looking forward to hearing from you about the reboot procedure you follow to help us reproduce the issue in Fedora 33. Thanks again! Kind regards
  3. @OpenSourcerer Hello! Your air-6to4 directive has an invalid argument, yes: it should be on. The returned error message "Unknown directive" is unexpected: that's another issue under investigation now. Can you confirm that air-6to4 on resolves the issue and tunnels IPv6 over IPv4 when the connection is over IPv4? Your suggestion during the internal beta testing has been adopted, but not yet implemented in beta 2. Starting from next release, yes - on - 1 - true on one side and no - off - 0 - false on the other side will be treated as equivalent arguments / synonyms by the parser. 👍 Kind regards
  4. Thanks! For that purpose, in vanilla OpenVPN you need as usual setenv UV_IPV6=yes - in AirVPN servers only of course - since when we started to support IPv6 fully. We failed to reproduce the "unknown directive" error for air-6to4 in goldcrest.rc - can you please check which exact char is after the "4" ? Maybe it is a parsing problem with blanks. The parser expects either \n , \t, \v or blank space. Kind regards
  5. @OpenSourcerer Yes, we are in an endless loop with Play Store. We submit for Android TV and it is rejected immediately (like, after a tenth of a second from the submission, it's like something set automatically to reject). We ask for a revision and a robot answers with a ton of conditions as pre-requisites for Android TV approval, which we already knew perfectly when we designed the application. We ask which condition is not met and a human answers that it is not allowed to open banners in an Android application. We ask which banner they talk about, and we are replied "banners in airvpn.org", with a years old screenshot, which was true years ago (the "banner" was simply the option to use that plug-in aimed at following threads more comfortably from mobile devices, we wiped it out a long ago), but not anymore since years. When we reply that it is no more true since years ago, we get silence from Google, and the app remains "incompatible with Android TV". We repeated the whole cycle with appeals and new requests at each new versio and we always experienced the identical loop (automatic rejection, bot response, human very old, identical pre-packaged response). We guess we should start a brand new project to get out of the vicious loop, maybe, and maybe we should suppress completely the web view routines in Eddie (which would be anyway not acceptable). Even if the banner was still in airvpn.org (which is not) then, according to the same logic, no browser should be approved for Android TV, because any browser can open a web site with a banner. Kind regards
  6. @OpenSourcerer OK! That's expected behavior. You need to set air-6to4 to on and connect in IPv4 if you wish IPv6 over IPv4. Please check and verify whether everything is OK. Explanation: since 2016 or 2017 our VPN servers are customized to push IPv6 routes only if client sends a user variable IPV6 containing value yes. Otherwise no IPv6 routes are pushed: that's necessary indeed, in order to avoid older OpenVPN versions numerous bugs on IPv6 and also make IPv4 connections possible to those systems which do not support IPv6, otherwise any OpenVPN version older than 2.5 would invoke "ip route" or "route" commands which would fail and cause OpenVPN to exit immediately. Insofar, a client must include directive setenv UV_IPV6=yes for OpenVPN to get IPv6 push and tunnel IPv6 over IPv4 (see also Configuration Generator generated profiles). Bluetit and Hummingbird will have OpenVPN3 library set IPV6 variable to yes only when air-6to4 is on and by default it is off. We are considering to change 6to4 to on by default, if IPv6 is detected as supported by the system. Kind regards
  7. Hello! That's strange because absolutely nothing changed in IPv6 detection between internal beta 1, beta 1 and beta 2. Let us know if the problem re-appears. Are IPv6 routes pushed by VPN servers and the push is ignored, or are IPv6 routes not pushed at all? Is 6to4 option on? Can we see the log and the settings pertaining to the 2nd problem. i.e.connection over IPv6 when IPv4 is expected? The expected behavior by Bluetit is: connect in IPv6 whenever user employs IPv6 remote addresses or options in Goldcrest, except when 6to4 option is active, in which case, if possible, connect in IPv4 and tunnel IPv6 over IPv4. Kind regards
  8. Hello! Google Play Store never approved Eddie for Android TV because it opens https://airvpn.org showing banners, according to Google. Of course this is not true (it's true that Eddie may open airvpn.org upon user's request, but it's not true that airvpn.org contains banners), but the ban is permanent for each release, so we can try to re-submit Eddie for Android TV only with a different release for the 15th time and see what happens. Kind regards
  9. Hello! For the reason we explained, common address pools in datacenters with (c) trolls. Not that it must be the case, of course. Kind regards
  10. Hello! Just in case: if the proper option is enabled, Eddie will start and connect at (re)boot only if it was running and was connected exclusively through a profile (and not with any other method) when the device was shut down previously. Also, some Android devices (for example all the Asus ones we know) include a boot application manager which by default will not authorize any app (apart from those by the manufacturer) to start at boot. Such boot managers must be configured additionally, for Android app clearance to start at boot is not sufficient. Kind regards
  11. @polomintus Hello! Can you take note whether the amount of peers receiving your chunks are the same both with and without VPN? If less peers ask for data chunks when you're in the VPN, it's possible that the other part of them use black lists blocking huge IP address pools common to us and copyright trolls and/or swarm poisoners (these two groups are not necessarily distinct ), hence your lower upload when in the VPN. Kind regards
  12. @User of AirVPN Congratulations! We confirm (and anyone connecting to the server monitor can do the same) that today we have had a 1.4 Gbit/s peak on Sharatan, so you were devouring most of the bandwidth. Can you also state the CPU, if you don't mind? Kind regards
  13. @polomintus Hello! The monitor correctly shows the amount of online sessions, not online users, connected to each VPN server (or country etc.). That said, Nash and Matar are in the same datacenter, have the same configuration and very similar hardware They are also served by the same transit providers. Therefore, so it's not easy to think of a satisfactory explanation. We could start from the fact that our servers in Alblasserdam are connected to a pool of several 10+ Gbit/s lines and more than one high volume router, but we can not see any symptom of congestion in any rack in Alblasserdam, as you indirectly noticed too. In any case, connect to the server(s) that can provide you with the best performance. Kind regards
  14. @pjnsmb Hello and thanks! Documentation remains the one you see. It will be updated when possible and anyway not later than stable version release date. At the moment it is perfectly valid for beta 2 version, you can rely on it safely. Kind regards
  15. UPDATE 27 NOVEMBER 2020 We're glad to announce that new version 1.0.0 beta 2 has been released featuring new OpenVPN 3 library supporting data-ciphers directive. The suite also fixes DNS issues with systemd-resolved when it is actively operating in "on link" mode and concurrently with network-manager in systemd based systems (it happens for example in Fedora 33). Please check the first message of the thread for a full overview and more details! Kind regards & datalove AirVPN Staff
  16. @stevewasabi69lol Hello! That's unexpected: it must be a bug in version 2.16.3 because servers have not been sending Halloween banner since weeks ago (now they send Black Friday promo banner). You can either upgrade to latest Eddie 2.19 (but you might have issues with Windows 7) or you can just delete all the files in C:\Users\parent\AppData\Local\AirVPN\ while Eddie is not running. At the next run you will need to re-enter your credentials and any custom setting. Kind regards
  17. Hello! We're very glad to inform you that the Black Friday week has just begun in AirVPN! Save up to 74% when compared to one month plan price Check all plans and discounts here: https://airvpn.org/buy If you're already our customer and you wish to jump aboard for a longer period, any additional subscription will be added on top of already existing subscriptions and you will not lose any day. AirVPN, one of the oldest and most experienced consumer VPN on the market, operating since 2010, does not inspect and/or log clients' traffic, offers five simultaneous connections per account, IPv6 full support, AES-GCM and ChaCha20 ciphers on all servers, Perfect Forward Secrecy with unique per-server 4096 bit Diffie-Hellman keys, active daemons load balancing for unmatched high performance and even more, exclusive features. AirVPN is the only VPN provider which is actively developing OpenVPN 3 library with a fork that's currently 91 commits ahead of OpenVPN master and adds key features and bug fixes for a much more comfortable and reliable experience: https://airvpn.org/forums/topic/44069-openvpn-3-development-by-airvpn/ AirVPN, in accordance with its mission, develops only free and open source software for many platforms, including Android, Linux (both x86 and ARM based systems), macOS and Windows. Kind regards & datalove AirVPN Staff
  18. @OpenSourcerer @Flx In general NSA is not able to break hard encryption so key exfiltration is mandatory to obtain encryption circumvention and not encryption "break". A more advanced stage is attacking the key exchange process (that explains why we already used 2048 bit DH keys since 2010 and shifted to 4096 bit DH keys in 2014, as well as 4096 bit RSA keys). Moreover, in the specific IPsec case, check the APEX VPN four phases according to top secret documents, for a summary on how NSA can successfully attack IPSec IKEv2 and ESP through HAMMERCHANT and HAMMERSTEIN. Unfortunately, how the decryption of ESP packets actually takes place remains unexplained. We know however that the decryption is real. "No details as to how the NSA decrypts those ESP — “Encapsulating Security Payload” — packets, although there are some clues in the form of code names in the slides." (Schneier). See also Bruce Schneier's blog and The Intercept publication of the relevant top secret document. On top of all that, in 2013 proof of the BULLRUN program emerged thanks to Snowden revelations. BULLRUN was a program aimed, among other things, at inserting vulnerabilities into commercial encryption systems. Nowadays it is strongly suspected that BULLRUN targeted IPsec too. We are talking about documents leaked in 2013 but related (even) to programs designed and developed during earlier years, so it's not unreasonable to assume that in the meantime NSA has further progressed to breaking IPsec. When we created AirVPN we decided to not adopt IPsec because already in 2010 doubts on NSA interference spread out as rumors. https://theintercept.com/document/2014/03/12/vpn-voip-exploitation-hammerchant-hammerstein/ https://www.schneier.com/blog/archives/2014/03/how_the_nsa_exp.html (check Q&A as well) Kind regards
  19. @traveller Hello! Yes, both Hummingbird and Eddie are free and open source software by AirVPN. They are available for Mac too. They both enforce "Network Lock" by using pf (pre-installed by default on macOS by Apple) so you don't have to worry about traffic leaks outside the VPN tunnel. Please see here: https://airvpn.org/macos Kind regards
  20. Hello! We inform you that the following servers located in the Netherlands: Anser Comae Elnath Jabbah Luhman Sheliak are having their IP addresses changed as a necessary datacenter restructuring. What you need to do If you run Eddie (all desktop and Android editions), data will be updated automatically. No action is required. If you have OpenVPN profiles pointing to those servers qualified domain names, everything will be updated automatically. No action is required. If you have OpenVPN profiles pointing directly to those servers IP addresses, you will necessarily have to re-generate such profiles. Kind regards AirVPN Staff
  21. Hello! More about macOS Big Sur, Eddie and Hummingbird. Eddie and Hummingbird enforce Network Lock through pf rules. The mentioned problem is that kernel extensions are deprecated, and the new API NetworkExtensions includes exceptions to filtering rules which allow 56 Apple apps and services to bypass any filtering rule enforced via the API (which is quite atrocious and says a lot about Apple's respect toward its customers, but that's how it is). However, pf is the system firewall which is autonomous from NetworkExtensions API and its exceptions. Therefore Eddie and Hummingbird Network Lock are working fine just as usual. Note that the NetworkExtensions exceptions were active even in Catalina. However, nobody noticed them because third-party firewalls bypassed them by relying on kernel extensions (kexts). Now that kexts don't work well anymore, the problem has exploded, but as usual you are safe with AirVPN Network Lock both in Eddie and Hummingbird. Kind regards
  22. Hello! Of course, the problem has nothing to do with Eddie Network Lock. Eddie and Hummingbird enforce Network Lock thorugh pf rules. The mentioned problem is that kernel extensions are deprecated, and the new API NetworkExtensions includes exceptions to filtering rules which allow 56 Apple apps and services to bypass any filtering rule enforced via the API. That's quite atrocious and says a lot about Apple's respect toward its customers, but that's how it is. However, pf is the system firewall which is autonomous from NetworkExtensions API and its exceptions. Therefore Eddie and Hummingbird Network Lock are working fine just as usual. Note that the NetworkExtensions exceptions were active even in Catalina. However, nobody noticed them because third-party firewalls bypassed them by relying on kernel extensions (kexts). Now that kexts don't work anymore, the problem has exploded, but as usual you are safe with AirVPN Network Lock both in Eddie and Hummingbird. Kind regards
  23. @X22Y55Zbc Hello and thank you!! You are free to buy any coupon quantity, but you can't provide a single coupon with multiple amounts. It's not a big deal because for your purpose you can buy two or more credit coupons and redeem them when you buy a plan in our "Buy" page. There, you will see a "Do you have a coupon code?" field in the upper section, where you can enter each coupon one by one, one after the other, and redeem all of them on a single purchase. The total amount of all coupons will be credited to the account that redeemed them. Such account can use all of its credit while checking out by clicking the proper button which appears on the checkout page. If in doubt or for any additional information please do not hesitate to open a ticket! Kind regards
  24. @183aTr78f9o Hello! it looks like a legitimate procedure to connect your machine at boot to some VPN server We can't see any peculiar problem with it. Kind regards
  25. @lostagain Hello! Eddie Android edition does not send any data to Google, so no reasons to worry about that. It also "contains" no trackers at all as you can verify here: https://reports.exodus-privacy.eu.org/en/reports/org.airvpn.eddie/latest/ Furthermore, you are not obliged to download Eddie from the Play Store, because we offer the APK through a direct download from our web sites, as you must already know. https://airvpn.org/forums/topic/29660-using-airvpn-with-eddie-client-for-android/ It's true, however, that you can't know whether some Android process by Google or the manufacturer of your device bypasses the VPN tunnel, as it happens in iOS with Apple services. However, it would be a common problem to all VPN apps and protocols, not Eddie specific. Kind regards
×
×
  • Create New...