Jump to content
Not connected, Your IP: 18.234.255.5

Staff

Staff
  • Content Count

    8635
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1231

Reputation Activity

  1. Like
    Staff got a reaction from Brainbleach in Wireguard plans   ...
    @Flx

    The first message was approved by some moderator in the wrong thread, not a big deal. Then we moved the message on its own thread, this one. Then user "wireguard" posted more messages which were all approved by some moderator.

    @Brainbleach

    Of course. We were replying to "wireguard" who invites surreptitiously to punish AirVPN because AirVPN uses and develops actively OpenVPN: "Needless to say, investing in AirVPN means investing in OpenVPN, and that's not acceptable to me at this point," . He/she also kept claiming that "it's time to retire OpenVPN" (sic), that OpenVPN is a "truly disgusting hack" (sic) and so on,. showing his/her embarrassing ignorance and lack of good faith. Nothing to do with your messages.

    Funny how bogus account writers are so eager to become from time to time AirVPN software lead developers, general managers for AirVPN strategies, marketing directors and more. ūüėÄ

    We wanted to prove beyond any reasonable doubt that his/her claim are unreasonable and based on wrong assumptions and terrible omissions, showing how Wireguard can not replace OpenVPN for a significant percentage of our customers and how our OpenVPN development has been beneficial for many users around the world.

    That said, we claimed that Wireguard needed to be developed and tested further years ago, so at the time our claim was totally reasonable. We also claimed years ago that the problem was not with CHACHA20 which to the best of nowadays knowledge is a very robust and secure cipher.

    Now the problems are different because Wireguard is asked to offer something which it was not designed for, i.e. providing some kind of anonymity layer. Such problems include lack of DNS push, lack of dynamic IP address assignment (with subsequent problems with client key-private address static correspondence, a very tough legal problem for us but above all for our customers), need of keeping client real IP address stored in a file. We have resolved them one by one with external software and internal work around. Once the problems are resolved in a robust way, which means testing thoroughly the adopted work-around, we can offer Wireguard, not earlier.

    Kind regards
     
  2. Like
    Staff got a reaction from stupid are cocksure in NetworkLock on macOS 11   ...
    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
     
  3. Like
    Staff got a reaction from vpnaccount77 in macOS BigSur   ...
    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

     
  4. Like
    Staff got a reaction from jeuia3e9x74uxu6wk0r2u9kdos in NetworkLock on macOS 11   ...
    @jeuia3e9x74uxu6wk0r2u9kdos
    @korsko
    @Overkill

    Hello!

    Both AirVPN software for macOS, Eddie and Hummingbird, enforce Network Lock via pf rules, therefore nothing changes and leaks prevention stays as effective as usual even in macOS Big Sur.

    Kind regards
     
  5. Thanks
    Staff reacted to pjnsmb in LINUX new software: AirVPN Suite 1.0 beta 1   ...
    @staff

    Thanks for the update
    for your information my system is linux unstable :

    System:
      Host: desktop Kernel: 5.9.9-towo.2-siduction-amd64 x86_64 bits: 64 
      Desktop: Cinnamon 4.6.7 
      Distro: siduction 18.3.0 Patience - cinnamon - (202010261730) 

    p.s. oops on the example - I have been running goldcrest as a normal user not as root...........ūüė≥

    regards
    pjnsmb
     
  6. Like
    Staff got a reaction from Brainbleach in Wireguard plans   ...
    @Flx

    The first message was approved by some moderator in the wrong thread, not a big deal. Then we moved the message on its own thread, this one. Then user "wireguard" posted more messages which were all approved by some moderator.

    @Brainbleach

    Of course. We were replying to "wireguard" who invites surreptitiously to punish AirVPN because AirVPN uses and develops actively OpenVPN: "Needless to say, investing in AirVPN means investing in OpenVPN, and that's not acceptable to me at this point," . He/she also kept claiming that "it's time to retire OpenVPN" (sic), that OpenVPN is a "truly disgusting hack" (sic) and so on,. showing his/her embarrassing ignorance and lack of good faith. Nothing to do with your messages.

    Funny how bogus account writers are so eager to become from time to time AirVPN software lead developers, general managers for AirVPN strategies, marketing directors and more. ūüėÄ

    We wanted to prove beyond any reasonable doubt that his/her claim are unreasonable and based on wrong assumptions and terrible omissions, showing how Wireguard can not replace OpenVPN for a significant percentage of our customers and how our OpenVPN development has been beneficial for many users around the world.

    That said, we claimed that Wireguard needed to be developed and tested further years ago, so at the time our claim was totally reasonable. We also claimed years ago that the problem was not with CHACHA20 which to the best of nowadays knowledge is a very robust and secure cipher.

    Now the problems are different because Wireguard is asked to offer something which it was not designed for, i.e. providing some kind of anonymity layer. Such problems include lack of DNS push, lack of dynamic IP address assignment (with subsequent problems with client key-private address static correspondence, a very tough legal problem for us but above all for our customers), need of keeping client real IP address stored in a file. We have resolved them one by one with external software and internal work around. Once the problems are resolved in a robust way, which means testing thoroughly the adopted work-around, we can offer Wireguard, not earlier.

    Kind regards
     
  7. Like
    Staff got a reaction from blaHbluBB in Wireguard plans   ...
    @wireguard

    User "wireguard" is not an account with a valid AirVPN plan  If you really wanted to show your support to AirVPN and prove that you are a customer, you would have written from an account with a valid plan. In reality, accounts like "wireguard" seem to be created with the only purpose to pump something and defame something else. From now on, write only from an account that has valid plan, to show that you are in good faith.

    Our plans about putting Wireguard into production in the near future have been published with a lot of details, albeit without a precise release date (and we have thoroughly explained why), so we will not write again for the nth time about them.

    About performance, please provide details as we do frequently. Currently we outperform Wireguard with our setup in AES-NI supporting systems, as you can see from our and our customers' tests, while Wireguard can outperform OpenVPN in CHACHA20 in non-AES-NI supporting systems.
    .
    When we put Wireguard into production, OpenVPN will stay, so investing in our own OpenVPN development is perfectly fine.

    Just a few reasons that make OpenVPN superior to Wireguard for many, different needs: it's faster than Wireguard in AES-NI supporting systems when it uses AES. Have a look here! it can be connected over stunnel, SSH, SOCKS5 and HTTP proxies, and Tor swiftly even for the above reason, for an ISP it's not so easy to block OpenVPN, while it's trivial to block Wireguard it supports TCP it supports dynamic IP address assignment it supports DNS push it does not hold in a file your real IP address when a connection is closed a significant part of our customers will not be able to use Wireguard effectively, simply because UDP is totally blocked in their countries or by their ISPs UDP blocking and heavy shaping are becoming more and more widespread among mobile ISPs, making Wireguard slower than OpenVPN in TCP even in mobile devices, or not working at all in mobility About Torvalds and Linux kernel, you only tell a part of the story. Wireguard was first put in some Linux kernel line when Wireguard was still in beta testing and no serious audit was performed, and not put in a kernel milestone release.

    A further note about battery draining you mentioned in one of your previous messages: our app Eddie Android edition and Wireguard, when used with the SAME bandwidth and the SAME cipher (CHACHA20-POLY1305), consume battery approximately in the same way, so that's yet another inessential point that does not support your arguments and show once more that our investments have been wise.

    Finally, let's spread a veil on your embarrassing considerations on ciphers, security, privacy and NSA. Let's underline only that CHACHA20.-POLY1305 is very strong, the cipher algorithm in itself (if implemented correctly) is not a Wireguard problem in any way.

    It would be a reason of deep concern if Wireguard needed OpenVPN defamation to convince us that it's a good software. Unfortunately various bogus accounts have been created with such assumption and purpose, and the hidden agenda is no more hidden.

    Kind regards
     
  8. Like
    Staff got a reaction from ecogit in Status of Eddie on Linux distributions   ...
    Last update: 16 May 2018 - Related to version: Eddie 2.14.4
    Any Linux distribution has at least:a different graphics server (X11, Wayland) a different desktop environment (GNOME, KDE, LXTE etc.) a package manager with a specific format (deb, rpm, tar.xf etc.) a different packaging signature for trust and security a different method to obtain administrative privileges, required by advanced features of Eddie (also because OpenVPN requires them) a different set of packages used by our client, that sometimes have different names (for example 'stunnel4' under Debian, 'stunnel' for Fedora) maybe a different DNS management. We are working at our best to support every kind of configuration managed by our source code directly, when possible.
     
    Tested without known issues
    Debian (tested 7/8/9) Ubuntu (18.04 GNOME tested) Ubuntu Mate (18.04 tested) Devuan (tested Ascii) Mint Arch (XFCE tested) Fedora (28 tested)

    With minimal issues
    openSUSE (Tumbleweed KDE tested)
    openSUSE (Tumbleweed GNOME tested)
      Works, with no tray icon. Elementary
      Works, but tray icon, web and folder links don't work.

    Fatal issues
     
    None known.


    Tech notes
    Sometimes Tray icon works, but it is not shown because the desktop environment hides it.
    For example, latest GNOME may require a separate shell extension (generally TopIcons). Currently Eddie 2.x under Linux requires root privileges (like GParted or Synaptic Manager).
    Elevation is generally obtained with a polkit policy file (pkexec) if installed, otherwise fallback methods are used when available (gksu, kdesu, beesu etc.).

    When the UI runs as root, there are four -optional- actions that are performed as normal user: tray icon, notifications, open web links and open file folders.
    If it is not possible to act as a normal user, such actions are not performed at all.

    A totally separated UI (as a normal user) vs. root-actions (as root user, service or separate process) is currently under development.

    Needed improvements
    Minimal lintian warnings on .deb edition General info details on .deb edition (for example, reporting Proprietary as License, not true.) General info details on .rpm edition (for example, reporting Proprietary as License, not true.) Create official package for AUR and other distributions. Create packages also for CLI-only edition. Create packages based on direct source compilation. Procedures to include Eddie in official/standard repository
  9. Like
    Staff got a reaction from ecogit in VPNs - Caught in Lying!?!   ...
    @arteryshelby

    We do not log and/or inspect our customers' traffic. Since 2010 you can't produce any single case, and not even the slightest clue, in which the identity of an AirVPN customer has been disclosed through traffic log and/or inspection and/or any other invasive method.

    It means a lot, given that various younger VPN services have been caught lying (ascertained court cases) and that AirVPN is now the oldest still active VPN service, with the exception of a minor service which anyway changed ownership twice in the last 12 years.

    By the way we have never asked our customers to blindly believe in our words.

    We do not block Tor and we even integrate its usage in our software, so you can be even safer if you can't afford to trust us OR some datacenter. For example you can use Tor over OpenVPN, to hide Tor usage to your country and ISP, and at the same time hide your traffic real origin, destination, protocol etc. to us and the datacenter the server is connected into.

    Last but not least, we invest a lo of money in Tor infrastructure and in 2017, 2018 and 2019 more than 2.5% of global world Tor network traffic transited on Tor exit-nodes paid by AirVPN. It is an important achievement we're proud of, and it hints to good faith.

    Kind regards
     
  10. Like
    Staff got a reaction from ecogit in China problem   ...
    Hello!

    The connection mode with the highest success rate (virtually 100%) according to our reports from China is toward port 443 (destination port not blocked by ISPs in China) of entry-IP address 3 (to have tsl-crypt and therefore full encryption of the Control Channel) in TCP (to bypass UDP blocks).

    DNS leaks are of course not a problem at all with our software.

    Kind regards
     
  11. Like
    Staff got a reaction from blaHbluBB in Wireguard plans   ...
    @wireguard

    User "wireguard" is not an account with a valid AirVPN plan  If you really wanted to show your support to AirVPN and prove that you are a customer, you would have written from an account with a valid plan. In reality, accounts like "wireguard" seem to be created with the only purpose to pump something and defame something else. From now on, write only from an account that has valid plan, to show that you are in good faith.

    Our plans about putting Wireguard into production in the near future have been published with a lot of details, albeit without a precise release date (and we have thoroughly explained why), so we will not write again for the nth time about them.

    About performance, please provide details as we do frequently. Currently we outperform Wireguard with our setup in AES-NI supporting systems, as you can see from our and our customers' tests, while Wireguard can outperform OpenVPN in CHACHA20 in non-AES-NI supporting systems.
    .
    When we put Wireguard into production, OpenVPN will stay, so investing in our own OpenVPN development is perfectly fine.

    Just a few reasons that make OpenVPN superior to Wireguard for many, different needs: it's faster than Wireguard in AES-NI supporting systems when it uses AES. Have a look here! it can be connected over stunnel, SSH, SOCKS5 and HTTP proxies, and Tor swiftly even for the above reason, for an ISP it's not so easy to block OpenVPN, while it's trivial to block Wireguard it supports TCP it supports dynamic IP address assignment it supports DNS push it does not hold in a file your real IP address when a connection is closed a significant part of our customers will not be able to use Wireguard effectively, simply because UDP is totally blocked in their countries or by their ISPs UDP blocking and heavy shaping are becoming more and more widespread among mobile ISPs, making Wireguard slower than OpenVPN in TCP even in mobile devices, or not working at all in mobility About Torvalds and Linux kernel, you only tell a part of the story. Wireguard was first put in some Linux kernel line when Wireguard was still in beta testing and no serious audit was performed, and not put in a kernel milestone release.

    A further note about battery draining you mentioned in one of your previous messages: our app Eddie Android edition and Wireguard, when used with the SAME bandwidth and the SAME cipher (CHACHA20-POLY1305), consume battery approximately in the same way, so that's yet another inessential point that does not support your arguments and show once more that our investments have been wise.

    Finally, let's spread a veil on your embarrassing considerations on ciphers, security, privacy and NSA. Let's underline only that CHACHA20.-POLY1305 is very strong, the cipher algorithm in itself (if implemented correctly) is not a Wireguard problem in any way.

    It would be a reason of deep concern if Wireguard needed OpenVPN defamation to convince us that it's a good software. Unfortunately various bogus accounts have been created with such assumption and purpose, and the hidden agenda is no more hidden.

    Kind regards
     
  12. Like
    Staff got a reaction from blaHbluBB in Wireguard plans   ...
    @wireguard

    User "wireguard" is not an account with a valid AirVPN plan  If you really wanted to show your support to AirVPN and prove that you are a customer, you would have written from an account with a valid plan. In reality, accounts like "wireguard" seem to be created with the only purpose to pump something and defame something else. From now on, write only from an account that has valid plan, to show that you are in good faith.

    Our plans about putting Wireguard into production in the near future have been published with a lot of details, albeit without a precise release date (and we have thoroughly explained why), so we will not write again for the nth time about them.

    About performance, please provide details as we do frequently. Currently we outperform Wireguard with our setup in AES-NI supporting systems, as you can see from our and our customers' tests, while Wireguard can outperform OpenVPN in CHACHA20 in non-AES-NI supporting systems.
    .
    When we put Wireguard into production, OpenVPN will stay, so investing in our own OpenVPN development is perfectly fine.

    Just a few reasons that make OpenVPN superior to Wireguard for many, different needs: it's faster than Wireguard in AES-NI supporting systems when it uses AES. Have a look here! it can be connected over stunnel, SSH, SOCKS5 and HTTP proxies, and Tor swiftly even for the above reason, for an ISP it's not so easy to block OpenVPN, while it's trivial to block Wireguard it supports TCP it supports dynamic IP address assignment it supports DNS push it does not hold in a file your real IP address when a connection is closed a significant part of our customers will not be able to use Wireguard effectively, simply because UDP is totally blocked in their countries or by their ISPs UDP blocking and heavy shaping are becoming more and more widespread among mobile ISPs, making Wireguard slower than OpenVPN in TCP even in mobile devices, or not working at all in mobility About Torvalds and Linux kernel, you only tell a part of the story. Wireguard was first put in some Linux kernel line when Wireguard was still in beta testing and no serious audit was performed, and not put in a kernel milestone release.

    A further note about battery draining you mentioned in one of your previous messages: our app Eddie Android edition and Wireguard, when used with the SAME bandwidth and the SAME cipher (CHACHA20-POLY1305), consume battery approximately in the same way, so that's yet another inessential point that does not support your arguments and show once more that our investments have been wise.

    Finally, let's spread a veil on your embarrassing considerations on ciphers, security, privacy and NSA. Let's underline only that CHACHA20.-POLY1305 is very strong, the cipher algorithm in itself (if implemented correctly) is not a Wireguard problem in any way.

    It would be a reason of deep concern if Wireguard needed OpenVPN defamation to convince us that it's a good software. Unfortunately various bogus accounts have been created with such assumption and purpose, and the hidden agenda is no more hidden.

    Kind regards
     
  13. Thanks
    Staff reacted to OpenSourcerer in LINUX new software: AirVPN Suite 1.0 beta 1   ...
    @Staff
    When enabled in goldcrest.rc, IPv6 is falsely detected as unsupported: $ sudo goldcrest -O -S Mesarthim
    2020-11-20 10:35:48 Reading run control directives from file /root/.config/goldcrest.rc
    Goldcrest 1.0.0 Beta 1 - 18 November 2020

    2020-11-20 10:35:48 Bluetit - AirVPN OpenVPN 3 Service 1.0.0 Beta 1 - 18 November 2020
    2020-11-20 10:35:48 OpenVPN core 3.6.6 AirVPN linux x86_64 64-bit
    2020-11-20 10:35:48 Bluetit is ready
    2020-11-20 10:35:48 Bluetit options successfully reset
    2020-11-20 10:35:48 ERROR: IPv6 is not available in this system

    $ip -o -6 a
    1: lo    inet6 ::1/128 scope host \       valid_lft forever preferred_lft forever
    2: enp39s0    inet6 2003:[…]/64 scope global temporary dynamic \       valid_lft 6843sec preferred_lft 1443sec
    2: enp39s0    inet6 2003:[…]/64 scope global dynamic mngtmpaddr noprefixroute \       valid_lft 6843sec preferred_lft 1443sec
    2: enp39s0    inet6 fe80::433c:773a:8904:118d/64 scope link noprefixroute \       valid_lft forever preferred_lft forever

    Failing if air-ipv6 and/or ipv6 are set to on. goldcrest.rc: #
    # goldcrest runcontrol file
    #

    # air-server            Mesarthim
    # air-tls-mode          <auto|auth|crypt>
    air-ipv6                on
    air-user                OpenSourcerer
    air-password            <that's my password, eh!>
    air-key                 <that's my key name, eh!>
    # cipher                <cipher_name>
    proto                   udp
    # server                <server_ip|server_url>
    port                    443
    # tcp-queue-limit       <n>
    # ncp-disable           <yes|no>
    network-lock            off
    ignore-dns-push         yes
    #ipv6                   on
    # timeout               <seconds>
    # compress              <yes|no|asym>
    # proxy-host            <host_ip|host_url>
    # proxy-port            <port>
    # proxy-username        <proxy_username>
    # proxy-password        <proxy_password>
    # proxy-basic           <yes|no>
    # alt-proxy             <yes|no>
    # persist-tun           <on|off>
  14. Thanks
    Staff got a reaction from Lee47 in CHACHA20-POLY1305 on all servers   ...
    Hello!



    We're very glad to announce all VPN servers progressive upgrade to Data Channel CHACHA20-POLY1305 cipher and TLS 1.3 support.
    UPDATE 18-Nov-2020: upgrade has been completed successfully on all AirVPN servers.

    The upgrade requires restarting OpenVPN daemons and some other service. Users connected to servers will be disconnected and servers during upgrade will remain unavailable for two minutes approximately. In order to prevent massive, simultaneous disconnections, we have scheduled a progressive upgrade in 15 days, starting from tomorrow 5 Nov 2020. Please see the exact schedule at the bottom of this post, in the attached PDF file. Servers marked as "OK" have been already upgraded and you can use CHACHA20-POLY1305 with them right now.
     
    When should I use CHACHA20-POLY1305 cipher on OpenVPN Data Channel?   In general, you should prefer CHACHA20 over AES on those systems which do not support AES-NI (AES New Instructions). CHACHA20 is computationally less onerous, but not less secure, than AES for CPUs that can't rely on AES New Instructions. If you have an AES-NI supporting CPU and system, on the contrary you should prefer AES for higher performance.
      How can I use CHACHA20-POLY1305 on AirVPN?
    CHACHA20-POLY1035 on Data Channel is supported by OpenVPN 2.5 or higher versions and OpenVPN3-AirVPN library.
    In Eddie Android edition, open "Settings" > "AirVPN" > "Encryption algorithm" and select CHACHA20-POLY1305. Eddie Android edition will then filter and connect to VPN servers supporting CHACHA20-POLY1305 and will use the cipher both on Control and Data channels.

    In our web site Configuration Generator, after you have ticked "Advanced Mode", you can pick OpenVPN version >=2.5, and also select "Prefer CHACHA20-POLY1305 cipher if available". If you're generating a configuration file for Hummingbird, select OpenVPN3-AirVPN: the configuration file needs to be different, because some new directives of OpenVPN 2.5 are not supported in OpenVPN3, and Hummingbird is based on OpenVPN3-AirVPN.

    In Eddie desktop edition, upgrade to 2.19.6 version first. Then select the above mentioned option. However, most desktop computers support AES-NI, so make sure to check first, because using CHACHA20-POLY1305 on such systems will cause performance harm when you go above 300 Mbit/s (if you stay below that performance, probably you will not notice any difference). Also note that if your system does not have OpenVPN 2.5 or higher version you will not be able to use CHACHA20-POLY1305.

    If you wish to manually edit your OpenVPN 2.5 profile to prefer CHACHA20 on Data Channel when available: delete directive cipher add the following directive: data-ciphers CHACHA20-POLY1305:AES-256-GCM

    Pending Upgrade Server Schedule


    Kind regards and datalove
    AirVPN Staff


     
  15. Thanks
    Staff got a reaction from sooprtruffaut in LINUX new software: AirVPN Suite 1.0 beta 1   ...
    @sooprtruffaut

    Hello and thank you!

    Watch out! Source code is not available during beta testing. As usual we will make it available with the stable release.

    Raspberry Pi OS 64 bit actually has old libraries and the suite will not run in it, we're sorry. When Raspberry OS 64 bit beta testing is over, we plan to support it as well.

    Kind regards
     
  16. Thanks
    Staff got a reaction from colorman in LINUX new software: AirVPN Suite 1.0 beta 1   ...
    @colorman

    Hello!

    For that you will need to wait for the client software with a Qt based GUI (Firecrest) which will interact with Bluetit as well, or the ncurses based TUI of Goldcrest will be fine for you, perhaps. Stay tuned.

    Kind regards
     
  17. Thanks
    Staff got a reaction from colorman in LINUX new software: AirVPN Suite 1.0 beta 1   ...
    Hello!

    We're very glad to introduce a new software suite for Linux which is ready for public beta testing.

    The suite includes the well known Hummingbird software, updated to the latest OpenVPN AirVPN library, and introduces for the first time a D-Bus controlled, real daemon, Bluetit, as well as a command line client, Goldcrest, to interact with Bluetit.

    The client-daemon architecture we introduce for the first time in our software offers a more robust security model and provides system administrators with a fine-grained, very flexible access control.

    Bluetit is fully integrated with AirVPN. The daemon is accessed through a D-Bus interface by providing specific methods and interface in order to give full support to OpenVPN connection and AirVPN functionality, including - but not limited to - quick automatic connection to the best AirVPN server for any specific location as well as any AirVPN server or country.

    When we get out of the beta testing, we plan to document Bluetit interface to let anyone write a custom client and talk with the daemon.

    Furthermore, Goldcrest will evolve in the near future and will include an ncurses based TUI which will be very comfortable when you don't want to rely on command line options while a new Bluetit client, based on Qt, will be developed in the future, for those who prefer a GUI.

    The suite is currently available for Linux x86-64, i686 (32 bit distributions), arm7l (for example Raspbian and other ARM 32 bit based systems) and aarch64 (ARM 64 bit).

    Please note that the source code will be published with the stable release as usual. The software will be licensed under GPLv3.
     
    AirVPN Suite for Linux
    AirVPN’s free and open source OpenVPN 3 suite based on AirVPN’s OpenVPN 3 library fork Version 1.0.0 Beta 1 - Release date 18 November 2020   Main features:
      Bluetit: lightweight D-Bus controlled system daemon providing full connectivity to AirVPN servers and generic OpenVPN servers Goldcrest: Bluetit client, allowing full integration with AirVPN servers, users, keys, profiles as well as generic OpenVPN servers Hummingbird: lightweight and standalone client for generic OpenVPN server connection Linux i686, x86-64, arm7l and arm64 (Raspberry) support Full integration with systemd, SysVStyle-init and chkconfig No heavy framework required, no GUI Tiny RAM footprint Lightning fast Based on OpenVPN 3 library fork by AirVPN version 3.6.6 with tons of critical bug fixes from the main branch, new cipher support and never seen before features ChaCha20-Poly1305 cipher support on both Control and Data Channel providing great performance boost on ARM, Raspberry PI and any Linux based platform not supporting AES-NI. Note: ChaCha20 support for Android had been already implemented in our free and open source Eddie Android edition Robust leaks prevention through Network Lock based either on iptables, nftables or pf through automatic detection Proper handling of DNS push by VPN servers, working with resolv.conf as well as any operational mode of systemd-resolved additional features   Full documentation:

    README.md Download links:
    Linux x86-64: https://eddie.website/repository/AirVPN-Suite/1.0-beta1/AirVPN-Suite-x86_64-1.0beta1.tar.gz
    Linux x-86-64 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-beta1/AirVPN-Suite-x86_64-1.0beta1.tar.gz.sha512

    Linux i686: https://eddie.website/repository/AirVPN-Suite/1.0-beta1/AirVPN-Suite-i686-1.0beta1.tar.gz
    Linux i686 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-beta1/AirVPN-Suite-i686-1.0beta1.tar.gz.sha512

    Linux arm7l: https://eddie.website/repository/AirVPN-Suite/1.0-beta1/AirVPN-Suite-armv7l-1.0beta1.tar.gz
    Linux arm7l sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-beta1/AirVPN-Suite-armv7l-1.0beta1.tar.gz

    Linux aarch64: https://eddie.website/repository/AirVPN-Suite/1.0-beta1/AirVPN-Suite-aarch64-1.0beta1.tar.gz
    Linux aarch64 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-beta1/AirVPN-Suite-aarch64-1.0beta1.tar.gz.sha512

      Please report bugs and any problem in this thread, thank you!
    Kind regards
    AirVPN Staff
     
  18. Thanks
    Staff reacted to Shiver Me Whiskers in speedtest comparison   ...
    Hello, I'm a bit of a noob when it comes to these things

    I downloaded Eddie 2.19.5, installed it on Windows 10, connected, and started downloading...
    It used "wintun", and I think connected via AES-256-GCM . 2020.11.19 16:28:18 - Eddie version: 2.19.5 / windows_x64, System: Windows, Name: Windows 10 Enterprise, Version: Microsoft Windows NT 10.0.19042.0, Mono/.Net: v4.0.30319 . 2020.11.19 16:28:19 - Tun Driver - 0901: 9.24.3; wintun: 0.8 . 2020.11.19 16:28:19 - OpenVPN - Version: 2.5.0 - OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10 (C:\Program Files\AirVPN\openvpn.exe) . 2020.11.19 16:28:19 - SSH - Version: plink 0.73 . 2020.11.19 16:28:19 - Build platform: 64-bit x86 Windows . 2020.11.19 16:28:19 - Compiler: clang 7.0.0 (tags/RELEASE_700/final), emulating Visual Studio 2013 (12.0), _MSC_VER=1800 . 2020.11.19 16:28:19 - Source commit: 745ed3ad3beaf52fc623827e770b3a068b238dd5 (C:\Program Files\AirVPN\plink.exe) . 2020.11.19 16:28:19 - SSL - Version: stunnel 5.56 (C:\Program Files\AirVPN\stunnel.exe) I 2020.11.19 16:28:20 - Ready . 2020.11.19 16:28:20 - Collect information about AirVPN completed I 2020.11.19 16:28:22 - Session starting. I 2020.11.19 16:28:22 - Checking authorization ... ! 2020.11.19 16:28:22 - Connecting to Tarazed (Netherlands, Alblasserdam) . 2020.11.19 16:28:23 - OpenVPN > OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020 . 2020.11.19 16:28:23 - OpenVPN > Windows version 10.0 (Windows 10 or greater) 64bit . 2020.11.19 16:28:23 - OpenVPN > library versions: OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10 . 2020.11.19 16:28:23 - OpenVPN > Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2020.11.19 16:28:23 - OpenVPN > Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2020.11.19 16:28:23 - OpenVPN > Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key . 2020.11.19 16:28:23 - OpenVPN > Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication . 2020.11.19 16:28:23 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]213.152.161.135:443 . 2020.11.19 16:28:23 - OpenVPN > Socket Buffers: R=[65536->262144] S=[65536->262144] . 2020.11.19 16:28:23 - OpenVPN > UDP link local: (not bound) . 2020.11.19 16:28:23 - OpenVPN > UDP link remote: [AF_INET]213.152.161.135:443 . 2020.11.19 16:28:23 - OpenVPN > TLS: Initial packet from [AF_INET]213.152.161.135:443, sid=f7f5cc8d 3b14c77f . 2020.11.19 16:28:23 - OpenVPN > VERIFY KU OK . 2020.11.19 16:28:23 - OpenVPN > Validating certificate extended key usage . 2020.11.19 16:28:23 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication . 2020.11.19 16:28:23 - OpenVPN > VERIFY EKU OK . 2020.11.19 16:28:23 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Tarazed, emailAddress=info@airvpn.org . 2020.11.19 16:28:23 - OpenVPN > Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, 4096 bit RSA . 2020.11.19 16:28:23 - OpenVPN > [Tarazed] Peer Connection Initiated with [AF_INET]213.152.161.135:443 ... . 2020.11.19 16:28:23 - OpenVPN > Data Channel: using negotiated cipher 'AES-256-GCM' . 2020.11.19 16:28:23 - OpenVPN > Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key . 2020.11.19 16:28:23 - OpenVPN > Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key ... . 2020.11.19 16:28:23 - OpenVPN > open_tun . 2020.11.19 16:28:23 - OpenVPN > wintun device [WinTUN] opened ... ! 2020.11.19 16:28:31 - Connected. . 2020.11.19 16:28:31 - OpenVPN > Initialization Sequence Completed
    (removed some unimportant stuff especially at the end to keep the log to keep it short, I have over 10 NIC devices due to use of VMs, makes the log huge)

    ISP is KPN (Netherlands), fiber, so I am pretty close to your VPN servers, 1 gbit plan ( 1000/500 )

    Computer config: AMD Ryzen 7 3700X, DDR4-3733 CL16, 2.5 gbits LAN all the way to the KPN Router (that came with the plan, didn't use any fancy expensive router)
    I think the AMD CPU has very good AES acceleration, because during those transfer I barely noticed any CPU utilization at all... like 20% on one single core ?
     
  19. Like
    Staff got a reaction from jeuia3e9x74uxu6wk0r2u9kdos in NetworkLock on macOS 11   ...
    @jeuia3e9x74uxu6wk0r2u9kdos
    @korsko
    @Overkill

    Hello!

    Both AirVPN software for macOS, Eddie and Hummingbird, enforce Network Lock via pf rules, therefore nothing changes and leaks prevention stays as effective as usual even in macOS Big Sur.

    Kind regards
     
  20. Like
    Staff got a reaction from mith_y2k in CHACHA20-POLY1305 on all servers   ...
    @mith_y2k

    Hello!

    You can simply re-start Hummingbird with the option you mention. Enjoy CHACHA20!

    Kind regards
     
  21. Thanks
    Staff reacted to abang in ipleak.net DNS zone is broken   ...
    This conclusion is wrong. I did not talk about the "Authority records". I wrote, the AA-bit in the DNS Flags is not set. And this violates the DNS protocol! Actually a "PowerDNS Recursor" can not resolve your domain name because the AA-bit was not set. And this is not a PowerDNS fault! It must be a configuration fault.
  22. Confused
    Staff reacted to Clodo in ipleak.net DNS zone is broken   ...
    This occurs because we use PowerDNS software.

    https://doc.powerdns.com/authoritative/appendices/FAQ.html

    IpLeak has this configuration since almost TEN years ago, it's very very difficult for us to think the issue is not yet resolved.
    Anyway, this is still under investigation, but currently we can't fix, we can't replace PowerDNS.
  23. Like
    Staff got a reaction from harold.lewis in Eddie Desktop 2.19beta released   ...
    @mazeman23

    Hello!

    OpenVPN 2.5_git you're running seems to not support data-ciphers, or the directive argument(s) is/are missing or illegal. Changing basic options on the run between beta , RC and stable versions seems not infrequent in OpenVPN development. Can you please re-check the OpenVPN version you're running? If it's really OpenVPN 2.5 stable, check the configuration file that Eddie generates (in "Stats" window double click the item pertaining to the generated OpenVPN profile), and examine the "data-ciphers" line (send the config to us as well if in doubt, cut certificates and keys).

    @harold.lewis

    "SSL not available" is what Eddie prints when it can't find stunnel (yes, it's a weird way to say it ).

    Kind regards
     
  24. Thanks
    Staff got a reaction from mrhippy in Hummingbird Errors   ...
    Hello!

    It's a bug, we have detected it and it will be fixed soon. To resolve the situation in the meantime: open a terminal type the command sudo rm /etc/airvpn/* set your favorite DNS with your system utilities Now Hummingbird will be able to run properly again.

    Kind regards
     
  25. Confused
    Staff got a reaction from Kmrfprink in Gazzetta - IT   ...
    Website: http://www.gazzetta.it
    La Gazzetta dello Sport, an Italian sport website and streaming.

    Status: OK
    Routing: All servers to IT route.
     
    Note: if you have an advertising blocker active (like Adblock or uBlock) try to disable it.
    This site detect use of this blocker and prevent to see the video.
√ó
√ó
  • Create New...