Staff

I noticed the same thing, I was connecting to a server in either Latvia or Sweden.

I updated "country" in /etc/airvpn/bluetit.rc to my Country and I started connecting to a server in a nearby Country.

I am on CentOS and I suspect either systemd or firewalld or selinux is stopping "something" from identifying my location.

I went looking because I noticed a message from goldcrest stating something like "could not identify location".  I do not remember the exact message.

After the change, all is well.
 

Hello!

We're very glad to inform you that a new 1 Gbit/s server located in Auckland (NZ) is available: Fawaris. We're also very pleased to be back in Oceania.

The AirVPN client will show automatically the new server. If you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP.

Just like every other Air server, Fawaris supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3 and tls-crypt.

Full IPv6 support is included as well.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

You can check the server status as usual in our real time servers monitor:
https://airvpn.org/servers/Fawaris

Do not hesitate to contact us for any information or issue.

Kind regards and datalove
AirVPN Team

Hello!

We're very glad to inform you that a new 1 Gbit/s server located in Auckland (NZ) is available: Fawaris. We're also very pleased to be back in Oceania.

The AirVPN client will show automatically the new server. If you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP.

Just like every other Air server, Fawaris supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3 and tls-crypt.

Full IPv6 support is included as well.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

You can check the server status as usual in our real time servers monitor:
https://airvpn.org/servers/Fawaris

Do not hesitate to contact us for any information or issue.

Kind regards and datalove
AirVPN Team

Hello!

We're very glad to inform you that a new 1 Gbit/s server located in Auckland (NZ) is available: Fawaris. We're also very pleased to be back in Oceania.

The AirVPN client will show automatically the new server. If you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP.

Just like every other Air server, Fawaris supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3 and tls-crypt.

Full IPv6 support is included as well.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

You can check the server status as usual in our real time servers monitor:
https://airvpn.org/servers/Fawaris

Do not hesitate to contact us for any information or issue.

Kind regards and datalove
AirVPN Team

Hello!

We're very glad to inform you that a new 1 Gbit/s server located in Auckland (NZ) is available: Fawaris. We're also very pleased to be back in Oceania.

The AirVPN client will show automatically the new server. If you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP.

Just like every other Air server, Fawaris supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3 and tls-crypt.

Full IPv6 support is included as well.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

You can check the server status as usual in our real time servers monitor:
https://airvpn.org/servers/Fawaris

Do not hesitate to contact us for any information or issue.

Kind regards and datalove
AirVPN Team

Hello!

We're very glad to inform you that a new 1 Gbit/s server located in Auckland (NZ) is available: Fawaris. We're also very pleased to be back in Oceania.

The AirVPN client will show automatically the new server. If you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP.

Just like every other Air server, Fawaris supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3 and tls-crypt.

Full IPv6 support is included as well.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

You can check the server status as usual in our real time servers monitor:
https://airvpn.org/servers/Fawaris

Do not hesitate to contact us for any information or issue.

Kind regards and datalove
AirVPN Team

Hello!

We're very glad to inform you that a new 1 Gbit/s server located in Auckland (NZ) is available: Fawaris. We're also very pleased to be back in Oceania.

The AirVPN client will show automatically the new server. If you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator").

The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP.

Just like every other Air server, Fawaris supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3 and tls-crypt.

Full IPv6 support is included as well.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses.

You can check the server status as usual in our real time servers monitor:
https://airvpn.org/servers/Fawaris

Do not hesitate to contact us for any information or issue.

Kind regards and datalove
AirVPN Team

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.
 
UPDATE 11-Dec-2020: version 1.0.0 Beta 3 has been released.
UPDATE 23-Dec-2020: version 1.0.0 RC 1 has been released

New architecture

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.

New OpenVPN 3 library features

Starting from version 1.0 beta 2, Hummingbird and Bluetit are linked against a new version of our OpenVPN 3 library which supports directive data-ciphers: it can be used consistently with OpenVPN 2.5 syntax in OpenVPN profiles.

The directive allows OpenVPN 3 based software to negotiate a common Data Channel cipher with the OpenVPN server,, updating therefore our library to ncp-like negotiation with OpenVPN 2 branch. Hummingbird and Bluetit are already linked against the new library version, while Eddie Android edition will be updated in the near future.

The new library also includes a different handling of IV_CIPHERS variable, fixing OpenVPN main branch issues causing a plethora of problems with OpenVPN 2.5. The implementation, at the same time, takes care of full backward compatibility with OpenVPN versions older than 2.5.

ncp-disable directive, which to date has never been implemented in the main  branch, is still supported, in order to further enhance backward compatibility with both OpenVPN profiles and servers, as well as connection flexibility with servers running older than 2.5 OpenVPN versions.
 
Please note that if you enforce a specific Data Channel cipher by means of Bluetit configuration file, Hummingbird line option, or Goldcrest configuration file and/or line option, the enforced Data Channel cipher will override data-ciphers profile directive.
 
Changelog 3.6.6 AirVPN  by ProMIND

- [ProMIND] [2020/11/02] openvpn/ssl/proto.hpp: IV_CIPHERS is set to the overridden cipher only
                         (both from client and/or OpenVPN profile) in order to properly work
                         with OpenVPN 2.5 IV_CIPHERS specifications. The old method of cipher
                         overriding by means of negotiable crypto parameters is still supported
                         in order to maintain compatibility with OpenVPN < 2.5.0
- [ProMIND] [2020/11/24] added "data-ciphers" directive to profile config .ovpn files in order
                         to comply to OpenVPN 2.5 negotiable data cipher specifications. In case
                         "data-ciphers" is found in the .ovpn files IV_CIPHERS is assigned to the
                         algorithms found in "data-ciphers". In this specific case, "cipher"
                         directive is used as a fallback cipher and, if not already specified in
                         "data-ciphers", is appended to IV_CIPHERS
 
 
Coming soon

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.
 
Notes on systemd-resolved

Version 1.0.0 beta 2 and subsequent versions fix a serious issue on systemd based systems running concurrently systemd-resolved and network-manager, for example Fedora 33 in its default configuration.

In Fedora 33 systemd-resolved comes pre-configured to work in "on-link" mode and network-manager works together with it.

This very peculiar, Windows-like setup finally kills Linux global DNS handling, adding to it those so far missing DNS leaks which made every Windows user nightmares more colorful. Any Microsoft system lacking the very concept of global DNS is now emulated, for an outstanding 30 years back time travel.. However, Hummingbird and Bluetit take care of preventing the brand new DNS leaks potentially caused by such smart setup, giving back Fedora + VPN users more peaceful nights.

Also note that systemd-resolved comes pre-configured with fallback DNS (Google DNS is a systemd-resolved default fallback DNS, smart choices pile up!) which will be queried if each interface DNS server fails some resolution. In such a case, if and only if you have Network Lock enabled DNS leaks will be prevented.
 
Supported systems

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.
 
Overview and main features
  AirVPN’s free and open source OpenVPN 3 suite based on AirVPN’s OpenVPN 3 library fork Version 1.0.0 Beta 2 - Relase date 27 November 2020 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-RC1/AirVPN-Suite-x86_64-1.0.0-RC-1.tar.gz
Linux x-86-64 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-x86_64-1.0.0-RC-1.tar.gz.sha512

Linux i686: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-i686-1.0.0-RC-1.tar.gz
Linux i686 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-i686-1.0.0-RC-1.tar.gz.sha512

Linux arm7l: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-armv7l-1.0.0-RC-1.tar.gz
Linux arm7l sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-armv7l-1.0.0-RC-1.tar.gz.sha512

Linux aarch64: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-aarch64-1.0.0-RC-1.tar.gz
Linux aarch64 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-aarch64-1.0.0-RC-1.tar.gz.sha512

  Please report bugs and any problem in this thread, thank you!
Kind regards
AirVPN Staff
 

@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
 

@OpenSourcerer

Hello!

It's a good idea. Actually we already have it (it is shown only to special users, we don't know if you can see it) so it would be simple to make it available to anyone. We will consider it seriously.

Kind regards
 

@OpenSourcerer

Hello!

It's a good idea. Actually we already have it (it is shown only to special users, we don't know if you can see it) so it would be simple to make it available to anyone. We will consider it seriously.

Kind regards
 

Hello!

Previous thread on Windows and Comodo to prevent DNS leaks and leaks in case of unexpected VPN disconnection have become very big and detailed. We invite you to consult those threads for details and support, while we publish this message as a quick, clarifying overview of the essential steps.

Please note that if you don't use Windows you don't need to read this post. If you use Windows and a firewall other than Comodo, you can anyway take these rules as an example and adapt them to your firewall.

This is a minimal set of instructions to prevent any leak in case of unexpected VPN disconnection and prevent, in any case, DNS leaks, on Windows system with Comodo firewall. Comodo firewall is currently the only firewall we recommend for Windows. The free version is just fine for our purposes.

Never rename the rules: in case you need support, we need to see what the rules really state.

1) If you're not familiar with a firewall, read Comodo Firewall manual or guides. In particular, please see the following:
https://help.comodo.com/topic-72-1-451-4773-global-rules.html
https://help.comodo.com/topic-72-1-451-4884-Network-Zones.html

2) Install Comodo Personal Firewall free version available here: https://personalfirewall.comodo.com/

3) Set the Firewall Security Level to "Custom Policy"
 


4) Determine or create the Network Zone of your TAP-Win32 network adapter (from now on "AirVPN"). A safe way to define it: IP Range [10.1.0.0 - 10.255.255.255]
 

 
if you need OpenVPN over SSH/SSL and other alternative connection modes, see also https://airvpn.org/specs
 
5) Determine the entry-IP addresses of the AirVPN server(s) you wish to connect to: https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses

6) Define a "Global Rule" which blocks everything:
Block And Log IP In/Out From MAC Any To MAC Any Where Protocol Is Any
The logging is important for troubleshooting if necessary.

7) Put the above Global Rule in the top position. This will block completely your connectivity and let you add a whitelist of Allow global rules put BEFORE this total block global rule. All the "Allow" rules that you want to be evaluated shall be put BEFORE (i.e. higher than) the above block rule.

8) Define a"Global" rule which allows in/out communications of your TAP-Win32 adapter ("AirVPN") both In and Out:
Allow IP In/Out From In [AirVPN] To MAC Any Where Protocol Is Any
Allow IP In/Out From MAC Any To In [AirVPN] Where Protocol Is Any

9) Do the same for your loopback zone (IP range 127.0.0.1 - 127.255.255.254)
Allow IP In/Out From In [Loopback Zone] to MAC Any Where Protocol Is Any
Allow IP In/Out From MAC Any To In [Loopback Zone] Where Protocol Is Any

10) Do the same for any entry-IP address of the VPN servers you wish to connect to. For example for Leporis:
Allow TCP or UDP In/Out From IP 95.211.191.33 To MAC Any Where Source Port Is Any And Destination Port Is Any
Allow TCP or UDP In/Out From MAC Any To IP 95.211.191.33 Where Source Port Is Any And Destination Port Is Any

For your comfort, you might define a Network Zone (for example [Air servers entry IPs]) containing only the entry-IP addresses of our servers and then set two rules like
Allow TCP or UDP In/Out From In [Air servers entry IPs] To MAC Any Where Source Port Is Any And Destination Port Is Any
Allow TCP or UDP In/Out From MAC Any To In [Air servers entry IPs] Where Source Port Is Any And Destination Port Is Any

In this way, you will only need to add a single IPv4 address to that Network Zone in order to connect to a new server, instead of defining two additional rules for each server, which may be annoying if you switch between a lot of servers.

11) Add similar rules to allow communications of your device with your router (and within your home/office network, if you wish so). For example, if your network is [192.168.0.0 / 255.255.0.0] define a network zone with IP Range [192.168.0.0 - 192.168.255.255] (let's call it "Home Network") and set the following rules:
Allow TCP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Any
Allow UDP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Not 53
Allow ICMP In/Out From In [Home Network] To In [Home Network] Where ICMP Message Is Any

11a) Allow DHCP "negotiation":
Allow IP In/Out From MAC Any To IP 255.255.255.255 Where Protocol Is Any
 

12) In order to allow "airvpn.org" resolution even when disconnected (and any other hostname you wish to be resolved even when VPN is disconnected), add to your hosts file the line:
95.211.138.143 airvpn.org
Do not forget about this change! If we change our main frontend IP address, you will not be able to reach airvpn.org anymore until you remove that line. No more necessary starting with Air client edition 2 "Eddie".


13) If you use the Air client, add rules to allow communications with IP addresses 5.196.64.52 and  95.211.138.143 (two of our frontend servers), In and Out
Allow TCP or UDP In/Out From IP 5.196.64.52 To MAC Any Where Source Port Is Any And Destination Port Is Any
Allow TCP or UDP In/Out From MAC Any To IP 5.196.64.52 Where Source Port Is Any And Destination Port Is Any
Allow TCP or UDP In/Out From IP 95.211.138.143 To MAC Any Where Source Port Is Any And Destination Port Is Any
Allow TCP or UDP In/Out From MAC Any To IP 95.211.138.143 Where Source Port Is Any And Destination Port Is Any

14) You can progressively enlarge your whitelist just by adding "Allow" rules before the total blocking rule of point 6) according to your system needs.

Keep in mind that there are literally dozens of ways to accomplish the same task with Comodo.

Pay attention not to confuse the "-" symbol, which stands for "IP range", with the "/" symbol, which stands for IP address / NetMask. For example, [10.4.0.0 - 10.9.255.255] is correct (the IP range from 10.4.0.0 to 10.9.255.255), while [10.4.0.0 / 10.9.255.255] is NOT correct (IP 10.4.0.0 NetMask 10.9.255.255, which covers almost every existing IP address!).

When you have defined all the rules, do not forget to click "Apply" and "OK" in order to store them and make them active for any new connection. Test everything and do not be afraid to experiment before you rely on the secured connection for sensitive data transmissions.

Kind regards

@busybee911

Hello!

After you have stopped and disabled systemd-resolved you should generate your own resolv.conf file before running Eddie, or restart networking and let network-manager do that (via DHCP etc.) if you wish to query the router. The new resolv.conf  file will then be the file that Eddie will restore when its job is finished.

Kind regards
 

@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
 

@McLoEa

Good to know, thank you for the info. We are checking how to address the issue with systemd-resolved working in that specific mode.

Kind regards
 

@McLoEa

Hello!

We don't know if it was you who pointed the support team to the following article in a ticket:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VPACQVWRG5HCWRPBIOTBAENRT6V6PRA4/

If not, the relevant part is:
systemd-resolved has various operational modes and Eddie, at the moment, can NOT handle properly the "on link" mode bypassing resolv.conf and relying on nss-resolve. In Fedora 33 systemd-resolved is configured by default in a way that Eddie does not handle correctly.

Hummingbird and Bluteit, in the AirVPN Suite, can handle correctly any systemd-resolved operational mode.

Disabling systemd-resolved, anyway, should resolve any issue with Eddie and OpenVPN DNS push. In a few words, the key is going back to handle DNS via resolv.conf file as usual.

If you wish to disable systemd-resolved: sudo systemctl stop systemd-resolved sudo systemctl disable systemd-resolved
IMPORTANT: create a new resolvc.conf file and/or restart network-manager service if necessary.

Kind regards
 

@fkeriviavcxjhvjke

Hello!

You have three options.

1) Run AirVPN Suite 1.0.0. It will take care properly of DNS push even when systemd-resolved is configured to work in on-link mode bypassing resolv..conf and even when it works together with network-manager. Tested successfully under new Fedora 33 default settings. The suite is free and open source software by AirVPN, based also on a robust client-daemon architecture, and offers Network Lock (for traffic leaks prevention) which works fine even in Fedora 33. See here:
https://airvpn.org/forums/topic/48435-linux-new-software-airvpn-suite-10-beta/

2) Disable systemd-resolved and re-create /etc/resolv.conf file to work with global DNS as usual, instead of the questionable and dangerous per-link basis mode. After that, you can either run AirVPN Suite 1.0.0, OpenVPN with update-resolv-conf script, or Eddie. Eddie is a free and open source software by AirVPN with a GUI running in Mono. Only when systemd-resolved is disabled or re-configured to respect /etc/resolv.conf, can Eddie be used in Fedora 33.

If you choose to run OpenVPN directly, remember that OpenVPN does not handle DNS push on Linux on the client side, so use the mentioned script. Please see here:
https://airvpn.org/forums/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/

3) Not recommended. Run OpenVPN with script update-resolved-systemd. Again see https://airvpn.org/forums/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/

Kind regards

 

Hello!
 
Nowadays, traffic shaping is a common practice. Several ISPs have evaluated that investing in traffic shaping techniques is better than investing in infrastructure expansion. Overselling becomes easier and the devastating congestion impact gets mitigated by enforcing penalties to all protocols which are rarely used by the majority of customers or that are more onerous for the infrastructure.
 
Protocols and traffic types are discovered in real time via SPI and DPI.
 
A VPN impairs traffic shaping techniques because it makes both SPI and DPI impotent. Therefore, ISPs that share the above vision (wild overselling and traffic shaping) need to shape VPN themselves, unconditionally. OpenVPN has a typical fingerprint, so it's easy to identify it with DPI. However, we provide connection modes which make OpenVPN not discernible. The most effective and at the same time efficient is a connection with "tls-crypt" which encrypts the whole OpenVPN Control Channel. It is available on entry-IP addresses 3 and 4 of our VPN servers.
 
Please test the following one (in Eddie desktop edition):
- from Eddie main window select "Preferences" > "Protocols"
- untick "Automatic"
- select the line with entry-IP address 3, port 443, protocol TCP. The row will be highlighted in blue
- click "Save"
 
tls-crypt will circumvent specific OpenVPN shaping, while TCP will get rid of UDP shaping, which is another commonly targeted protocol.
 
UDP might be shaped or not in your line, so it's worth that you try it too.
 
Eddie Android edition 2.0 connects to entry-IP address 3 by default. You might anyway need to change the protocol from UDP to TCP in the "Settings" if UDP is throttled.
 
Kind regards

I'll second this. I barely know my way around the deeper details of a Linux system and getting the suite going, including automatic connection on boot, was very simple. Awesome work and I completely agree on the superb documentation; so rare to see this.

I'd love to see this as a package at some point. Some greater guidance on password security might not go amiss.

@frpergflf

Hello!

Allowing access to those directories to group "airvpn" is a choice of each superuser. For security reasons, by default the installer sets them belonging to root user and root or wheel group to comply to the best security practices consolidated in UNIX in the last 30 years. In general, as an optimal security solution, we want that Bluetit files can be edited only by root and sudo-ers, while Goldcrest files (but not Goldcrest binary) can be changed only by users belonging to airvpn group.

The lock file removal failure after Bluetit clean stop order by systemd is unexpected. When the problem re-occurs, would you be so kind to send us Bluetit log? sudo journalctl | grep bluetit

@asdfasdfasdfasdfasdf

No, it is not. If you proceed to implement, don't forget that Bluetit is a daemon.

@dL4l7dY6
@airvpnclient

A source of Bluetit instability in OSMC and Raspbian 32 bit has been detected, and it's libcurl . The linked library explodes now and then. The problem has been resolved with specific libcurl linking. Development is now focused on a new Network Lock approach, to make the whole environment more secure especially during a system bootstrap. Once it is implemented (a matter of just a few days) we will be ready for testing and soon after a new release will follow, perfectly compatible with OSMC too.

Kind regards
 

@Terry Stanford

Hello!

If you run Eddie GUI, you can configure Eddie to activate Network Lock at startup, check "Activate Network Lock at start" in "Preferences" windows. You can also configure Eddie to connect when it is launched.

If you run Eddie CLI, in a screen or tmux session run something like "sleep n && eddie-cli <options here>" where n is in seconds.

Kind regards
 

@frpergflf

Hello!

SELinux correctly prevents systemd to delete the lock file. That's an illegal operation that systemd wants to perform and that tells something on how systemd is designed.

Bleutit crash is caused by the fact that systemd bombards with SIGTERM Bluetit (and in general any real daemon). Under specific circumstances, i.e. when 2 or more SIGTERM signals are sent to Blueit almost simultaneously, Bluetit crashes, because the promise object has been already depleted when the 2nd or nth SIGTERM is received. Again, this incomprehensible behavior tells something about how systemd is designed, but at least it made us find a bug which might cause crashes in any other similar circumstance (imagine if you manage to send SIGTERM from two "kill" commands synced to be executed almost simultaneously).

Fix will be of course implemented in the next, imminent version.

Kind regards
 

@Maggie144

Hello!

Since Network Lock is enforced via pf rules, which act directly on the kernel filtering table, it is not plausible that Apple services can bypass them. Leaks observed on Catalina and Big Sur with other software (not our software) take place because filtering rules are enforced via specific network API. The specific network filtering exceptions (for Apple programs) hard coded in macOS Catalina and Big Sur filtering API, which caused a lot of controversies (and rightly so), allow the horrendous behavior.

Actually, lack of traffic leaks when Eddie or Hummingbird Network Lock is active on Intel Mac has been thoroughly verified by us through external network sniffers. We confirm that nothing, including Apple services and apps, is able to bypass the firewall (pf) rules. We can perform the same verification on Mac M1 in the near future.

The problem in iOS is worse and can't be resolved, because in iOS devices you are not in control of the device filtering table (and you are not in control of the device in general). Anyway we do not write software for iOS, as you know. Should, in the future, "Apple Silicon" platforms evolve in iOS-like system which the user can not control, then they will be unsuitable for purposes where privacy and a layer of anonymity are a priority. We doubt anyway that Apple will expel its own customers from administrative device control like it did with iOS, but let's wait and see.

Kind regards
 

@Maggie144

Hello!

Since Network Lock is enforced via pf rules, which act directly on the kernel filtering table, it is not plausible that Apple services can bypass them. Leaks observed on Catalina and Big Sur with other software (not our software) take place because filtering rules are enforced via specific network API. The specific network filtering exceptions (for Apple programs) hard coded in macOS Catalina and Big Sur filtering API, which caused a lot of controversies (and rightly so), allow the horrendous behavior.

Actually, lack of traffic leaks when Eddie or Hummingbird Network Lock is active on Intel Mac has been thoroughly verified by us through external network sniffers. We confirm that nothing, including Apple services and apps, is able to bypass the firewall (pf) rules. We can perform the same verification on Mac M1 in the near future.

The problem in iOS is worse and can't be resolved, because in iOS devices you are not in control of the device filtering table (and you are not in control of the device in general). Anyway we do not write software for iOS, as you know. Should, in the future, "Apple Silicon" platforms evolve in iOS-like system which the user can not control, then they will be unsuitable for purposes where privacy and a layer of anonymity are a priority. We doubt anyway that Apple will expel its own customers from administrative device control like it did with iOS, but let's wait and see.

Kind regards
 

@frpergflf

Hello!

Allowing access to those directories to group "airvpn" is a choice of each superuser. For security reasons, by default the installer sets them belonging to root user and root or wheel group to comply to the best security practices consolidated in UNIX in the last 30 years. In general, as an optimal security solution, we want that Bluetit files can be edited only by root and sudo-ers, while Goldcrest files (but not Goldcrest binary) can be changed only by users belonging to airvpn group.

The lock file removal failure after Bluetit clean stop order by systemd is unexpected. When the problem re-occurs, would you be so kind to send us Bluetit log? sudo journalctl | grep bluetit

@asdfasdfasdfasdfasdf

No, it is not. If you proceed to implement, don't forget that Bluetit is a daemon.

@dL4l7dY6
@airvpnclient

A source of Bluetit instability in OSMC and Raspbian 32 bit has been detected, and it's libcurl . The linked library explodes now and then. The problem has been resolved with specific libcurl linking. Development is now focused on a new Network Lock approach, to make the whole environment more secure especially during a system bootstrap. Once it is implemented (a matter of just a few days) we will be ready for testing and soon after a new release will follow, perfectly compatible with OSMC too.

Kind regards