Linux: AirVPN Suite 1.1.0 beta available

[Staff 9972]

@pjnsmb

Hello!

gb3.ipv6.vpn.airdns.org is updated correctly, so Bluetit will connect to the correct server that domain resolves into.

The failure to resolve names during Bluetit start at bootstrap but the ability to do so afterwards remains a problem which we could not reproduce so far. It was detected in Raspbian and OSMC, due to their settings which cause systemd to run Bluetit prematurely, and fixed by implementing in Bluetit its own network link detection.

Kind regards
 

[air2157 4]

I've created a fresh Debian 10 VM for testing hummingbird and it's now failing at startup. It's very likely something to do with the VM's config but what's wrong isn't clear.

Here's the config file:
 

# script-security 2
client
dev tun
remote europe3.all.vpn.airdns.org 443
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
route-delay 5
verb 3
push-peer-info
setenv UV_IPV6 no
remote-cert-tls server
cipher AES-256-GCM
comp-lzo no
proto tcp-client
# up up.sh
# down down.sh

When I run hummingbird:

user@vpn-client:~$ sudo /usr/local/bin/hummingbird /etc/openvpn/airvpn/europe-all-tcp.conf
Hummingbird - AirVPN OpenVPN 3 Client 1.1.2 RC3 - 16 April 2021

Fri May  7 19:26:12.795 2021 System and service manager in use is systemd
ERROR: merge config error: MERGE_OVPN_EXT_FAIL : ERR_PROFILE_NO_OVPN_EXTENSION: europe-all-tcp.conf

The config file works fine with OpenVPN 2.5.2:

user@vpn-client:~$ sudo /usr/sbin/openvpn --cd /etc/openvpn --config /etc/openvpn/airvpn/europe-all-tcp.conf 
2021-05-07 19:35:11 OpenVPN 2.5.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 21 2021
2021-05-07 19:35:11 library versions: OpenSSL 1.1.1d  10 Sep 2019, LZO 2.10
2021-05-07 19:35:11 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2021-05-07 19:35:11 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2021-05-07 19:35:11 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2021-05-07 19:35:11 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2021-05-07 19:35:14 TCP/UDP: Preserving recently used remote address: [AF_INET]134.19.179.165:443
2021-05-07 19:35:14 Socket Buffers: R=[131072->131072] S=[16384->16384]
2021-05-07 19:35:14 Attempting to establish TCP connection with [AF_INET]134.19.179.165:443 [nonblock]
2021-05-07 19:35:14 TCP connection established with [AF_INET]134.19.179.165:443
2021-05-07 19:35:14 TCP_CLIENT link local: (not bound)
2021-05-07 19:35:14 TCP_CLIENT link remote: [AF_INET]134.19.179.165:443
2021-05-07 19:35:14 TLS: Initial packet from [AF_INET]134.19.179.165:443, sid=f6fd7a74 c61641da
2021-05-07 19:35:14 VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
2021-05-07 19:35:14 VERIFY KU OK
2021-05-07 19:35:14 Validating certificate extended key usage
2021-05-07 19:35:14 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2021-05-07 19:35:14 VERIFY EKU OK
2021-05-07 19:35:14 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Melnick, emailAddress=info@airvpn.org
2021-05-07 19:35:15 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1552', remote='link-mtu 1604'
2021-05-07 19:35:15 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA512'
2021-05-07 19:35:15 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, peer certificate: 4096 bit RSA, signature: RSA-SHA512
2021-05-07 19:35:15 [Melnick] Peer Connection Initiated with [AF_INET]134.19.179.165:443
2021-05-07 19:35:15 PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway  def1 bypass-dhcp,dhcp-option DNS 10.34.23.1,route-gateway 10.34.23.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.34.23.128 255.255.255.0,peer-id 0,cipher AES-256-GCM'
2021-05-07 19:35:15 OPTIONS IMPORT: timers and/or timeouts modified
2021-05-07 19:35:15 OPTIONS IMPORT: compression parms modified
2021-05-07 19:35:15 OPTIONS IMPORT: --ifconfig/up options modified
2021-05-07 19:35:15 OPTIONS IMPORT: route options modified
2021-05-07 19:35:15 OPTIONS IMPORT: route-related options modified
2021-05-07 19:35:15 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2021-05-07 19:35:15 OPTIONS IMPORT: peer-id set
2021-05-07 19:35:15 OPTIONS IMPORT: adjusting link_mtu to 1627
2021-05-07 19:35:15 OPTIONS IMPORT: data channel crypto options modified
2021-05-07 19:35:15 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-05-07 19:35:15 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-05-07 19:35:15 ROUTE_GATEWAY 192.168.8.1/255.255.255.0 IFACE=ens3 HWADDR=52:54:00:4f:84:4e
2021-05-07 19:35:15 TUN/TAP device tun0 opened
2021-05-07 19:35:15 /sbin/ip link set dev tun0 up mtu 1500
2021-05-07 19:35:15 /sbin/ip link set dev tun0 up
2021-05-07 19:35:15 /sbin/ip addr add dev tun0 10.34.23.128/24
2021-05-07 19:35:20 /sbin/ip route add 134.19.179.165/32 via 192.168.8.1
2021-05-07 19:35:20 /sbin/ip route add 0.0.0.0/1 via 10.34.23.1
2021-05-07 19:35:20 /sbin/ip route add 128.0.0.0/1 via 10.34.23.1
2021-05-07 19:35:20 Initialization Sequence Completed

 

[OpenSourcerer 1435]

51 minutes ago, air2157 said:

ERROR: merge config error: MERGE_OVPN_EXT_FAIL : ERR_PROFILE_NO_OVPN_EXTENSION: europe-all-tcp.conf

The error seems to be obvious, the file must have the .ovpn extension.

[air2157 4]

Thanks. Fair point, though it makes little sense.

@StaffPerhaps the devs can remove this check.

First, the check is not in accordance with the documentation, which simply says:

usage: hummingbird [options] <config-file>

There is no restriction on the file suffix mentioned anywhere in the documentation.

Second, on Linux systems, it's more usual to use the .conf file suffix than .ovpn. Here's the Debian 10 systemd command line for openvpn-client@.service.:

ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf

Insisting that it must be .ovpn will create incompatibility issues with OpenVPN on Linux -- and IMO is an unnecessary and counter-productive restriction.





 

[OpenSourcerer 1435]

2 hours ago, air2157 said:

There is no restriction on the file suffix mentioned anywhere in the documentation.

I agree with you here. It hints at sloppy work on documentation, and the fact there is no man page for Hummingbird makes this argument only stronger.

2 hours ago, air2157 said:

Second, on Linux systems, it's more usual to use the .conf file suffix than .ovpn. Here's the Debian 10 systemd command line for openvpn-client@.service.:

Is it? The way I see it, it doesn't matter at all. As long as OpenVPN can read a plain text file and parse its contents, it's regarded as a valid OpenVPN config. Try it yourself, it can be .cpp, .odt or even .exe.

2 hours ago, air2157 said:

Insisting that it must be .ovpn will create incompatibility issues with OpenVPN on Linux -- and IMO is an unnecessary and counter-productive restriction.

I agree again. It's like restricting passwords to be max 14 characters and without specials except dot, hyphen and underscore… who the hell comes up with such absurd restrictions? 😡

[Staff 9972]

@air2157

Quote

Insisting that it must be .ovpn will create incompatibility issues with OpenVPN on Linux -- and IMO is an unnecessary and counter-productive restriction.

Hello!

We think you're right.

If confirmed, it does not seem as an Hummingbird limitation at all: we must check twice but at a first glance we have dragged such a limitation from the main branch of OpenVPN 3 library, specifically here:
https://github.com/OpenVPN/openvpn3/blob/master/openvpn/options/merge.hpp

when OpenVPN3 wants to merge additional profile (about which, we will have some questions for you after some tests, stay tuned ).

We have already widely rewritten critical OpenVPN 3 parts in our fork, fixed dozens of bugs and conceptually wrong code, added new key features and essential directives, and we will rewrite even this part if it comes out that it's a counter-productive implementation by the main branch developers that we missed. Again, we will not hesitate to rewrite other code whenever the main branch code is inappropriate, after we have consulted with the development leader, as we have always done.

Thank you for having found out the issue and reported it to us.

@OpenSourcerer

Quote

I agree with you here. It hints at sloppy work on documentation,

In this case the documentation is correct, as Hummingbird does not enforce limitation on the file name.

Work on Hummingbird documentation has received excellent feedback (dozens of positive comments), readers please check here:
https://airvpn.org/suite/readme/
https://airvpn.org/hummingbird/readme/

However, and obviously, anything can be improved. Is there anybody else here who can give us an additional feedback about Hummingbird & Suite documentation?

OpenVPN3 main branch is undocumented while its source code is poorly commented, so it may have happened that a peculiar feature, especially when it is as "strange" as it seems in this case, has been missed. Luckily, nothing that justifies the "sloppy" adjective, in our opinion.

Quote

and the fact there is no man page for Hummingbird makes this argument only stronger.

Remember that we offer a README.md specific to HB which is much more complete than a man page (you can't of course stuff the whole readme.md in the man pages).

man pages had been planned for the AirVPN Suite and not for Hummingbird, since Hummingbird had been considered a binary which can be launched by Eddie, while as a stand alone binary it was just transitional software to show what our AirVPN OpenVPN 3 library could do, before we had a real daemon, Bluetit, whose version 1.1.0 release has now the priority.

Of course now that Hummingbird appears to have reached such a wide appreciation and success (which we did not expect) we may change our plans, in order to maintain Hummingbird not only as an Eddie alternative to OpenVPN (Hummingbird in Intel Mac and in M1 Mac provides a 2x throughput boost against OpenVPN 2.5), but also as a part of the Suite.

Next step is publishing the developer's manual for Bluetit, our first and only real daemon, which we deem as very important. Then we can consider man pages specific to the Suite and in that occasion we can re-think about Hummingbird man pages, because at the of the day we offer a much more complete documentation than a man page.

Quote

I agree again. It's like restricting passwords to be max 14 characters and without specials except dot, hyphen and underscore… who the hell comes up with such absurd restrictions? 😡

We totally agree with you.

If the restriction is confirmed OpenVPN3 main branch developers might be asked about why they think it is appropriate to enforce it, anyway we have seen worse things in the original source code. On our side, we will verify the problem and we will remove it if confirmed, luckily we forked OpenVPN 3 a long ago so we have no constraints.

Our fork is now 103 commits ahead the main branch, and we assure you that we are determined to wipe out any other OpenVPN3 main branch "absurdity", according to your definition, we find.

Kind regards

[air2157 4]

11 hours ago, OpenSourcerer said:

Is it? The way I see it, it doesn't matter at all. As long as OpenVPN can read a plain text file and parse its contents, it's regarded as a valid OpenVPN config. Try it yourself, it can be .cpp, .odt or even .exe.

I understand that the file suffix isn't important when running the OpenVPN program from the command line. The issue here is that Debian (and at least Fedora, which also uses systemd) allow you to run a systemd service by running sudo systemctl start openvpn@europe which, in this example, will use the config file /etc/openvpn/europe.conf.  In this case, the .conf suffix is baked into the systemd service file. Debian also has an /etc/default/openvpn file that can be used to start OpenVPN at system startup, which also requires the config file to have a .conf suffix. So this whole .conf / .ovpn issue in Linux(es) derives from the way OpenVPN is stitched into the operating system, not from the OpenVPN program itself.

@Staff  Thank you for your positive and understanding response. As you might recall, I tested the Bluetit / Goldcrest combo and decided that it didn't mesh with my needs. If possible, I would certainly encourage you to maintain Hummingbird as part of the AirVPN suite. For my part, a man page isn't a high priority if I can get the documentation online.

[OpenSourcerer 1435]

1 hour ago, Staff said:

Our fork is now 103 commits ahead the main branch, and we assure you that we are determined to wipe out any other OpenVPN3 main branch "absurdity", according to your definition, we find.

Is OpenVPN3-AirVPN development upstreamed in some way? If you're here fixing bugs like pest control, I can imagine the OpenVPN3 dev team being truly grateful for the help if all that is upstreamed.
 

40 minutes ago, air2157 said:

I understand that the file suffix isn't important when running the OpenVPN program from the command line. The issue here is that Debian (and at least Fedora, which also uses systemd) allow you to run a systemd service by running sudo systemctl start openvpn@europe which, in this example, will use the config file /etc/openvpn/europe.conf.  In this case, the .conf suffix is baked into the systemd service file. Debian also has an /etc/default/openvpn file that can be used to start OpenVPN at system startup, which also requires the config file to have a .conf suffix. So this whole .conf / .ovpn issue in Linux(es) derives from the way OpenVPN is stitched into the operating system, not from the OpenVPN program itself.

Rename it yourself? Sounds like you need to move the file before you can use systemctl, anyway.

[Staff 9972]

2 hours ago, air2157 said:

@Staff  Thank you for your positive and understanding response. As you might recall, I tested the Bluetit / Goldcrest combo and decided that it didn't mesh with my needs. If possible, I would certainly encourage you to maintain Hummingbird as part of the AirVPN suite. For my part, a man page isn't a high priority if I can get the documentation online.

 
Hello!

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

Kind regards
 

[air2157 4]

1 hour ago, OpenSourcerer said:

Rename it yourself? Sounds like you need to move the file before you can use systemctl, anyway.

Could you explain further? What is "it" in this context?

[Staff 9972]

4 hours ago, OpenSourcerer said:

Is OpenVPN3-AirVPN development upstreamed in some way? If you're here fixing bugs like pest control, I can imagine the OpenVPN3 dev team being truly grateful for the help if all that is upstreamed.

Hello!

Of course. Not only OpenVPN-AirVPN code is clean, clearly commented and can be maintained efficiently (Donald Knuth is an ideal master of the AirVPN suite developer chief ) but we also submitted pull requests initially for the master branch, before we forked..

An OVPN3 project leader and some other person reminded us that pull requests could not be accepted if AirVPN did not disclose the real identity of its developers, and if AirVPN did not accept the re-licensing clause specified in the CLA.rst contract stating that OpenVPN Inc., and only OpenVPN Inc., can re-license our code under any other license, including "non open" licenses (Part, II, https://github.com/OpenVPN/openvpn3/blob/master/CLA.rst)

Both conditions were and are not accepted by AirVPN, and we were forced to fork. Therefore, upstream must be performed by third-parties or by OpenVPN Inc. itself, but remember that we do not agree to the mentioned contract, especially in the part which states that code may be re-licensed by OpenVPN Inc. under any other license.

Currently, the following modifications by AirVPN can be of particular interest for the main branch:

• the (N_)RECONNECT bug fix in Linux
• the data channel cipher selection bug fix
• the new implementation of Data Channel cipher negotiation compatible with OpenVPN 2.5 new method as well as the older OpenVPN 2 implementation
• the "ncp-disable" directive implementation (it comes handy with older than OpenVPN 2.5 servers)
• the "data-ciphers" directive implementation
• the fix of the "explosion" bug triggered under apparently random circumstances, in reality due to the unbelievable lack of data structure initialization in at least five different parts of the code
• the cleaner rewrite of the options parser getting rid of a good amount of parsing bugs
• the new method to select the correct cipher for each packet with pointer to methods in place of a dumb, and slower, series of "if" in the main branch which are executed at every and each outgoing or incoming packet block (useful when it's linked against mbedTLS)
• many other bug fixes which would make this message too long for this thread - being 103 commits ahead, you really have a more stable, more OpenVPN 2 compatible, and faster library now

Kind regards
 

[OpenSourcerer 1435]

2 hours ago, air2157 said:

Could you explain further? What is "it" in this context?

The config file? When you move it to /etc/openvpn/, you can rename it at the same time. Change the extension to .conf then

[air2157 4]

1 hour ago, OpenSourcerer said:

The config file? When you move it to /etc/openvpn/, you can rename it at the same time. Change the extension to .conf then

I see. It already has a .conf extension, which is why if currently fails with Hummingbird.

I think that the easiest workaround for now is simply to have a .conf file and create a link to it with an extension of .ovpn so, for example, file europe.conf has a link to it named europe.ovpn (or vice versa). That'll keep both OpenVPN/systemd and Hummingbird happy.

The issue is whether we should need to use such a workaround.

Anyway, thanks for your help.

[air2157 4]

On 4/26/2021 at 5:37 PM, Staff said:

The failure to resolve names during Bluetit start at bootstrap but the ability to do so afterwards remains a problem which we could not reproduce so far. It was detected in Raspbian and OSMC, due to their settings which cause systemd to run Bluetit prematurely,

Just a FYI, since you've already fixed this but:

On OSMC you can ensure that a systemd service correctly waits for network-online.target by enabling connman-wait-for-network.service.

On Raspbian / RaspiOS, there is an option in raspi-config to wait for network at boot (currently option S6)..

[OpenSourcerer 1435]

2 hours ago, air2157 said:

The issue is whether we should need to use such a workaround.

It is what it is, as you wrote. You could also edit the systemd unit file, but I think the next upgrade will reset it back.

[Staff 9972]

14 hours ago, air2157 said:

Just a FYI, since you've already fixed this but:

On OSMC you can ensure that a systemd service correctly waits for network-online.target by enabling connman-wait-for-network.service.

On Raspbian / RaspiOS, there is an option in raspi-config to wait for network at boot (currently option S6)..

Hello!

Correct. Of course it's not that systemd has been fixed, but the problem has been fixed in the sense that no workaround is anymore necessary because now Bluetit verifies by itself the connectivity link, so it does need to trust anymore any init system. Only when the link is up (network interface up WITH a default gateway according to the kernel, and not according to anything else) Bluetit starts network operations, thus avoiding any error.

The matter became relevant because default Raspbian and OSMC settings cause systemd to run those services which are targeted to start only after the link is up even when the link is not up, a mixture of bad systemd behavior and questionable settings which expose such behavior.

Kind regards
 

[Staff 9972]

@air2157
 

Quote

see. It already has a .conf extension, which is why if currently fails with Hummingbird.

I think that the easiest workaround for now is simply to have a .conf file and create a link to it with an extension of .ovpn so, for example, file europe.conf has a link to it named europe.ovpn (or vice versa). That'll keep both OpenVPN/systemd and Hummingbird happy.

Hello!

We confirm that Hummingbird does not enforce restrictions on profile name and that OpenVPN 3 enforces restriction on the suffix of the file name. We managed to reproduce the issue easily, even when a merge is not requested. The merge.hpp class has been modified very recently (25 days ago) and that might perhaps explain why the problem has never been reported in years.

We will seriously consider to remove this limitation.

Kind regards
 

[msbntt 0]

Is there any way of using up/down scripts with bluetit?

I've looked but can't find the answer anywhere. If it's not currently possible, would you consider adding the ability to do so?

[air2157 4]

7 hours ago, msbntt said:

Is there any way of using up/down scripts with bluetit?

If you're using a systemd-based version of Linux you could consider using ExecStartPost= and ExecStopPost= to run your up and down shell scripts, respectively. It might not meet your needs 100% but if there's no other alternative, it's probably worth a go.

https://www.freedesktop.org/software/systemd/man/systemd.service.html

[air2157 4]

I'm having problems running a SIGUSR2 with Hummingbird.

As I understand things, it should reset the tunnel and (for my test) puck up a different IP address.

Config file:
 

script-security 2
client
dev tun
remote europe3.vpn.airdns.org 443
resolv-retry infinite
nobind
persist-key
#persist-tun
auth-nocache
route-delay 5
verb 3
push-peer-info
setenv UV_IPV6 no
remote-cert-tls server
cipher AES-256-GCM
comp-lzo no
proto tcp-client
#up up.sh
#down down.sh

Before state:

user@vpn-client:~$ ip ro
0.0.0.0/1 via 10.28.123.1 dev tun0
default via 192.168.8.1 dev ens3 onlink
10.28.123.0/24 dev tun0 proto kernel scope link src 10.28.123.68
128.0.0.0/1 via 10.28.123.1 dev tun0
192.168.8.0/24 dev ens3 proto kernel scope link src 192.168.8.17
213.152.162.86 via 192.168.8.1 dev ens3
user@vpn-client:~$ cat /etc/resolv.conf
#
# Created by AirVPN. Do not edit.
#
# Your resolv.conf file is temporarily backed up in /etc/airvpn/resolv.conf.airvpnbackup
# To restore your resolv.conf file you need to log in as root
# and execute the below command from the shell:
#
# mv /etc/airvpn/resolv.conf.airvpnbackup /etc/resolv.conf
#

nameserver 10.28.123.1
user@vpn-client:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:4f:84:4e brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.17/24 brd 192.168.8.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe4f:844e/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 200
    link/none
    inet 10.28.123.68/24 brd 10.28.123.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::df6b:ccad:e3be:3587/64 scope link stable-privacy
       valid_lft forever preferred_lft forever
user@vpn-client:~$ systemctl status hummingbird@airvpn
● hummingbird@airvpn.service - Hummingbird connection to airvpn
   Loaded: loaded (/etc/systemd/system/hummingbird@.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2021-05-11 20:53:30 BST; 1min 22s ago
 Main PID: 366 (hummingbird)
    Tasks: 2 (limit: 1149)
   Memory: 9.1M
   CGroup: /system.slice/system-hummingbird.slice/hummingbird@airvpn.service
           └─366 /usr/local/bin/hummingbird /etc/openvpn/airvpn.ovpn

After state:

user@vpn-client:~$ sudo kill -USR2 366
[sudo] password for user:
user@vpn-client:~$ systemctl status hummingbird@airvpn
● hummingbird@airvpn.service - Hummingbird connection to airvpn
   Loaded: loaded (/etc/systemd/system/hummingbird@.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2021-05-11 20:53:30 BST; 2min 11s ago
 Main PID: 366 (hummingbird)
    Tasks: 2 (limit: 1149)
   Memory: 9.1M
   CGroup: /system.slice/system-hummingbird.slice/hummingbird@airvpn.service
           └─366 /usr/local/bin/hummingbird /etc/openvpn/airvpn.ovpn
user@vpn-client:~$ ip ro
default via 192.168.8.1 dev ens3 onlink
192.168.8.0/24 dev ens3 proto kernel scope link src 192.168.8.17
user@vpn-client:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:4f:84:4e brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.17/24 brd 192.168.8.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe4f:844e/64 scope link
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 200
    link/none
user@vpn-client:~$ ping -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
^C
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

System journal after SIGUSR2

May 11 20:55:32 vpn-client hummingbird[366]: Received SIGUSR2 signal. Reconnecting VPN.
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.114 2021 Client terminated, reconnecting in 0...
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.114 2021 net_route_del: 128.0.0.0/1 via 10.28.123.1 dev tun0 table 0 metric 0
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.114 2021 net_route_del: 0.0.0.0/1 via 10.28.123.1 dev tun0 table 0 metric 0
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.114 2021 net_addr_del: 10.28.123.68/24 dev tun0
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.114 2021 net_iface_mtu_set: mtu 1500 for tun0
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.114 2021 net_iface_up: set tun0 down
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.118 2021 net_route_del: 213.152.162.86/32 via 192.168.8.1 dev ens3 table 0 metric 0
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.118 2021 Tue May 11 20:55:32.140 2021 EVENT: RECONNECTING
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.140 2021 Successfully restored DNS settings
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.140 2021 ERROR: N_RECONNECT
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.140 2021 EVENT: RESOLVE
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.143 2021 Resolved server europe3.vpn.airdns.org into IPv4 213.152.162.86
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.143 2021 Adding IPv4 server 213.152.162.86 to network filter
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.578 2021 Network filter and lock successfully activated
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.584 2021 Contacting 213.152.162.86:443 via TCPv4
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.584 2021 EVENT: WAIT
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.584 2021 Tue May 11 20:55:32.640 2021 Connecting to [europe3.vpn.airdns.org]:443 (213
.152.162.86) via TCPv4
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.692 2021 EVENT: CONNECTING
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.694 2021 Tunnel Options:V4,dev-type tun,link-mtu 1524,tun-mtu 1500,proto TCPv4_CLIENT
,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.694 2021 Peer Info:
May 11 20:55:32 vpn-client hummingbird[366]: IV_VER=3.7 AirVPN
May 11 20:55:32 vpn-client hummingbird[366]: IV_PLAT=linux
May 11 20:55:32 vpn-client hummingbird[366]: IV_NCP=2
May 11 20:55:32 vpn-client hummingbird[366]: IV_TCPNL=1
May 11 20:55:32 vpn-client hummingbird[366]: IV_PROTO=30
May 11 20:55:32 vpn-client hummingbird[366]: IV_CIPHERS=AES-256-GCM
May 11 20:55:32 vpn-client hummingbird[366]: IV_LZO_STUB=1
May 11 20:55:32 vpn-client hummingbird[366]: IV_COMP_STUB=1
May 11 20:55:32 vpn-client hummingbird[366]: IV_COMP_STUBv2=1
May 11 20:55:32 vpn-client hummingbird[366]: UV_IPV6=no
May 11 20:55:32 vpn-client hummingbird[366]: IV_GUI_VER=Hummingbird - AirVPN OpenVPN 3 Client 1.1.2 RC3
May 11 20:55:32 vpn-client hummingbird[366]: IV_SSL=OpenSSL 1.1.0l  10 Sep 2019
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.771 2021 VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emai
lAddress=info@airvpn.org, signature: RSA-SHA1
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.775 2021 VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Rukbat/emailAddres
s=info@airvpn.org, signature: RSA-SHA512
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.978 2021 SSL Handshake: peer certificate: CN=Rukbat, 4096 bit RSA, cipher: TLS_CHACHA
20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.978 2021 Session is ACTIVE
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.978 2021 EVENT: WARN TLS: received certificate signed with SHA1. Please inform your a
dmin to upgrade to a stronger algorithm. Support for SHA1 signatures will be dropped in the future
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.979 2021 EVENT: GET_CONFIG
May 11 20:55:32 vpn-client hummingbird[366]: Tue May 11 20:55:32.979 2021 Sending PUSH_REQUEST to server...
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.125 2021 OPTIONS:
May 11 20:55:33 vpn-client hummingbird[366]: 0 [comp-lzo] [no]
May 11 20:55:33 vpn-client hummingbird[366]: 1 [redirect-gateway] [def1] [bypass-dhcp]
May 11 20:55:33 vpn-client hummingbird[366]: 2 [dhcp-option] [DNS] [10.28.123.1]
May 11 20:55:33 vpn-client hummingbird[366]: 3 [route-gateway] [10.28.123.1]
May 11 20:55:33 vpn-client hummingbird[366]: 4 [topology] [subnet]
May 11 20:55:33 vpn-client hummingbird[366]: 5 [ping] [10]
May 11 20:55:33 vpn-client hummingbird[366]: 6 [ping-restart] [60]
May 11 20:55:33 vpn-client hummingbird[366]: 7 [ifconfig] [10.28.123.68] [255.255.255.0]
May 11 20:55:33 vpn-client hummingbird[366]: 8 [peer-id] [0]
May 11 20:55:33 vpn-client hummingbird[366]: 9 [cipher] [AES-256-GCM]
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.126 2021 PROTOCOL OPTIONS:
May 11 20:55:33 vpn-client hummingbird[366]:   cipher: AES-256-GCM
May 11 20:55:33 vpn-client hummingbird[366]:   digest: NONE
May 11 20:55:33 vpn-client hummingbird[366]:   ncp enabled: yes
May 11 20:55:33 vpn-client hummingbird[366]:   key-derivation: OpenVPN PRF
May 11 20:55:33 vpn-client hummingbird[366]:   compress: LZO_STUB
May 11 20:55:33 vpn-client hummingbird[366]:   peer ID: 0
May 11 20:55:33 vpn-client hummingbird[366]:   control channel: tls-crypt enabled
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.126 2021 EVENT: ASSIGN_IP
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.126 2021 VPN Server has pushed IPv4 DNS server 10.28.123.1
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.158 2021 Setting pushed IPv4 DNS server 10.28.123.1 in resolv.conf
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.159 2021 net_iface_mtu_set: mtu 1500 for tun0
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.161 2021 net_iface_up: set tun0 up
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.162 2021 net_addr_add: 10.28.123.68/24 brd 10.28.123.255 dev tun0
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.162 2021 net_route_add: 0.0.0.0/1 via 10.28.123.1 dev tun0 table 0 metric 0
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.163 2021 net_route_add: 128.0.0.0/1 via 10.28.123.1 dev tun0 table 0 metric 0
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.163 2021 net_route_del: 128.0.0.0/1 via 10.28.123.1 dev tun0 table 0 metric 0
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.163 2021 net_route_del: 0.0.0.0/1 via 10.28.123.1 dev tun0 table 0 metric 0
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.163 2021 net_addr_del: 10.28.123.68/24 dev tun0
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.163 2021 net_iface_mtu_set: mtu 1500 for tun0
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.164 2021 net_iface_up: set tun0 down
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.164 2021 Connected via tun
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.164 2021 LZO-ASYM init swap=0 asym=1
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.165 2021 Comp-stub init swap=0
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.165 2021 EVENT: CONNECTED europe3.vpn.airdns.org:443 (213.152.162.86) via /TCPv4 on t
un/10.28.123.68/ gw=[10.28.123.1/]
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.165 2021 Server has pushed its own DNS. Removing system DNS from network filter.
May 11 20:55:33 vpn-client hummingbird[366]: iptables: Bad rule (does a matching rule exist in that chain?).
May 11 20:55:33 vpn-client hummingbird[366]: Tue May 11 20:55:33.179 2021 System DNS 192.168.14.1 is now rejected by the network filter

It fails a little differently when persist-tun is enabled -- but it still fails.

Running SIGUSR2 a second time kills all network connectivity to/from the VM, which is then accessible only via the console.

Edit: To keep the log shorter, I'm showing the result for europe3.vpn.airdns.org. In reality, I'm going to be accessing europe3.all.vpn.airdns.org





 

[Staff 9972]

@air2157

Hello!

--persist-tun option is mandatory to perform a successful re-connection. Without persist-tun you should lose the tun interface (then routing table as well as Network Lock prevent leaks, that's why you note you lose connectivity).

Can you please re-check? We ask because we can't reproduce the issue. Please note that without persist-tun, it's expected that re-connection
fails and your network is locked. Note that Bluetit keeps persist-tun on by default, while Hummingbird keeps persist-tun off by default.

Kind regards
 

[air2157 4]

1 hour ago, Staff said:

Can you please re-check? We ask because we can't reproduce the issue

It's a Debian 10 (stretch) image, so uses nftables by default.

I already mentioned that I tested it with persist-tun. It fails.

Config file:

script-security 2
client
dev tun
remote europe3.vpn.airdns.org 443
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
route-delay 5
verb 3
push-peer-info
setenv UV_IPV6 no
remote-cert-tls server
cipher AES-256-GCM
comp-lzo no
proto tcp-client
#up up.sh
#down down.sh

Before state:

user@vpn-client:~$ ip ro
0.0.0.0/1 via 10.15.187.1 dev tun0
default via 192.168.8.1 dev ens3 onlink
10.15.187.0/24 dev tun0 proto kernel scope link src 10.15.187.71
128.0.0.0/1 via 10.15.187.1 dev tun0
192.168.8.0/24 dev ens3 proto kernel scope link src 192.168.8.17
194.187.251.165 via 192.168.8.1 dev ens3
user@vpn-client:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:4f:84:4e brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.17/24 brd 192.168.8.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe4f:844e/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 200
    link/none
    inet 10.15.187.71/24 brd 10.15.187.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::2698:d295:7130:774b/64 scope link stable-privacy
       valid_lft forever preferred_lft forever
user@vpn-client:~$ systemctl status hummingbird@airvpn
● hummingbird@airvpn.service - Hummingbird connection to airvpn
   Loaded: loaded (/etc/systemd/system/hummingbird@.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-05-12 16:34:38 BST; 2min 24s ago
 Main PID: 366 (hummingbird)
    Tasks: 2 (limit: 1149)
   Memory: 9.1M
   CGroup: /system.slice/system-hummingbird.slice/hummingbird@airvpn.service
           └─366 /usr/local/bin/hummingbird /etc/openvpn/airvpn.ovpn

After state:

user@vpn-client:~$ sudo kill -USR2 366
[sudo] password for user:
user@vpn-client:~$ systemctl status hummingbird@airvpn
● hummingbird@airvpn.service - Hummingbird connection to airvpn
   Loaded: loaded (/etc/systemd/system/hummingbird@.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-05-12 16:34:38 BST; 3min 20s ago
 Main PID: 366 (hummingbird)
    Tasks: 2 (limit: 1149)
   Memory: 9.1M
   CGroup: /system.slice/system-hummingbird.slice/hummingbird@airvpn.service
           └─366 /usr/local/bin/hummingbird /etc/openvpn/airvpn.ovpn
user@vpn-client:~$ ip ro
default via 192.168.8.1 dev ens3 onlink
192.168.8.0/24 dev ens3 proto kernel scope link src 192.168.8.17
user@vpn-client:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:4f:84:4e brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.17/24 brd 192.168.8.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe4f:844e/64 scope link
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 200
    link/none
user@vpn-client:~$ ping -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
^C
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

user@vpn-client:~$ cat /etc/resolv.conf
#
# Created by AirVPN. Do not edit.
#
# Your resolv.conf file is temporarily backed up in /etc/airvpn/resolv.conf.airvpnbackup
# To restore your resolv.conf file you need to log in as root
# and execute the below command from the shell:
#
# mv /etc/airvpn/resolv.conf.airvpnbackup /etc/resolv.conf
#

nameserver 10.15.187.1

System journal:

May 12 16:37:47 vpn-client hummingbird[366]: Received SIGUSR2 signal. Reconnecting VPN.
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.474 2021 Client terminated, reconnecting in 0...
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.474 2021 net_route_del: 128.0.0.0/1 via 10.15.187.1 dev tun0 table 0 metric 0
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.474 2021 net_route_del: 0.0.0.0/1 via 10.15.187.1 dev tun0 table 0 metric 0
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.474 2021 net_addr_del: 10.15.187.71/24 dev tun0
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.474 2021 net_iface_mtu_set: mtu 1500 for tun0
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.474 2021 net_iface_up: set tun0 down
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.478 2021 net_route_del: 194.187.251.165/32 via 192.168.8.1 dev ens3 table 0 metric 0
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.478 2021 Wed May 12 16:37:47.491 2021 EVENT: RECONNECTING
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.491 2021 Successfully restored DNS settings
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.491 2021 ERROR: N_RECONNECT
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.492 2021 EVENT: RESOLVE
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.494 2021 Resolved server europe3.vpn.airdns.org into IPv4 194.187.251.165
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.494 2021 Adding IPv4 server 194.187.251.165 to network filter
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.908 2021 Network filter and lock successfully activated
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.917 2021 Contacting 194.187.251.165:443 via TCPv4
May 12 16:37:47 vpn-client hummingbird[366]: Wed May 12 16:37:47.918 2021 EVENT: WAIT
May 12 16:37:48 vpn-client hummingbird[366]: Wed May 12 16:37:47.918 2021 Wed May 12 16:37:48.004 2021 Connecting to [europe3.vpn.airdns.org]:443 (194
.187.251.165) via TCPv4
May 12 16:37:48 vpn-client hummingbird[366]: Wed May 12 16:37:48.430 2021 EVENT: CONNECTING
May 12 16:37:48 vpn-client hummingbird[366]: Wed May 12 16:37:48.433 2021 Tunnel Options:V4,dev-type tun,link-mtu 1524,tun-mtu 1500,proto TCPv4_CLIENT
,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client
May 12 16:37:48 vpn-client hummingbird[366]: Wed May 12 16:37:48.433 2021 Peer Info:
May 12 16:37:48 vpn-client hummingbird[366]: IV_VER=3.7 AirVPN
May 12 16:37:48 vpn-client hummingbird[366]: IV_PLAT=linux
May 12 16:37:48 vpn-client hummingbird[366]: IV_NCP=2
May 12 16:37:48 vpn-client hummingbird[366]: IV_TCPNL=1
May 12 16:37:48 vpn-client hummingbird[366]: IV_PROTO=30
May 12 16:37:48 vpn-client hummingbird[366]: IV_CIPHERS=AES-256-GCM
May 12 16:37:48 vpn-client hummingbird[366]: IV_LZO_STUB=1
May 12 16:37:48 vpn-client hummingbird[366]: IV_COMP_STUB=1
May 12 16:37:48 vpn-client hummingbird[366]: IV_COMP_STUBv2=1
May 12 16:37:48 vpn-client hummingbird[366]: UV_IPV6=no
May 12 16:37:48 vpn-client hummingbird[366]: IV_GUI_VER=Hummingbird - AirVPN OpenVPN 3 Client 1.1.2 RC3
May 12 16:37:48 vpn-client hummingbird[366]: IV_SSL=OpenSSL 1.1.0l  10 Sep 2019
May 12 16:37:48 vpn-client hummingbird[366]: Wed May 12 16:37:48.532 2021 VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emai
lAddress=info@airvpn.org, signature: RSA-SHA1
May 12 16:37:48 vpn-client hummingbird[366]: Wed May 12 16:37:48.535 2021 VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Diadema/emailAddre
ss=info@airvpn.org, signature: RSA-SHA512
May 12 16:37:48 vpn-client hummingbird[366]: Wed May 12 16:37:48.814 2021 SSL Handshake: peer certificate: CN=Diadema, 4096 bit RSA, cipher: TLS_CHACH
A20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
May 12 16:37:48 vpn-client hummingbird[366]: Wed May 12 16:37:48.814 2021 Session is ACTIVE
May 12 16:37:48 vpn-client hummingbird[366]: Wed May 12 16:37:48.814 2021 EVENT: WARN TLS: received certificate signed with SHA1. Please inform your a
dmin to upgrade to a stronger algorithm. Support for SHA1 signatures will be dropped in the future
May 12 16:37:48 vpn-client hummingbird[366]: Wed May 12 16:37:48.815 2021 EVENT: GET_CONFIG
May 12 16:37:48 vpn-client hummingbird[366]: Wed May 12 16:37:48.815 2021 Sending PUSH_REQUEST to server...
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.816 2021 Sending PUSH_REQUEST to server...
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.844 2021 OPTIONS:
May 12 16:37:49 vpn-client hummingbird[366]: 0 [comp-lzo] [no]
May 12 16:37:49 vpn-client hummingbird[366]: 1 [redirect-gateway] [def1] [bypass-dhcp]
May 12 16:37:49 vpn-client hummingbird[366]: 2 [dhcp-option] [DNS] [10.15.187.1]
May 12 16:37:49 vpn-client hummingbird[366]: 3 [route-gateway] [10.15.187.1]
May 12 16:37:49 vpn-client hummingbird[366]: 4 [topology] [subnet]
May 12 16:37:49 vpn-client hummingbird[366]: 5 [ping] [10]
May 12 16:37:49 vpn-client hummingbird[366]: 6 [ping-restart] [60]
May 12 16:37:49 vpn-client hummingbird[366]: 7 [ifconfig] [10.15.187.71] [255.255.255.0]
May 12 16:37:49 vpn-client hummingbird[366]: 8 [peer-id] [0]
May 12 16:37:49 vpn-client hummingbird[366]: 9 [cipher] [AES-256-GCM]
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.844 2021 PROTOCOL OPTIONS:
May 12 16:37:49 vpn-client hummingbird[366]:   cipher: AES-256-GCM
May 12 16:37:49 vpn-client hummingbird[366]:   digest: NONE
May 12 16:37:49 vpn-client hummingbird[366]:   ncp enabled: yes
May 12 16:37:49 vpn-client hummingbird[366]:   key-derivation: OpenVPN PRF
May 12 16:37:49 vpn-client hummingbird[366]:   compress: LZO_STUB
May 12 16:37:49 vpn-client hummingbird[366]:   peer ID: 0
May 12 16:37:49 vpn-client hummingbird[366]:   control channel: tls-crypt enabled
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.844 2021 EVENT: ASSIGN_IP
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.844 2021 VPN Server has pushed IPv4 DNS server 10.15.187.1
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.869 2021 Setting pushed IPv4 DNS server 10.15.187.1 in resolv.conf
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.870 2021 net_iface_mtu_set: mtu 1500 for tun0
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.870 2021 net_iface_up: set tun0 up
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.871 2021 net_addr_add: 10.15.187.71/24 brd 10.15.187.255 dev tun0
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.871 2021 net_route_add: 0.0.0.0/1 via 10.15.187.1 dev tun0 table 0 metric 0
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.872 2021 net_route_add: 128.0.0.0/1 via 10.15.187.1 dev tun0 table 0 metric 0
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.872 2021 net_route_del: 128.0.0.0/1 via 10.15.187.1 dev tun0 table 0 metric 0
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.872 2021 net_route_del: 0.0.0.0/1 via 10.15.187.1 dev tun0 table 0 metric 0
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.872 2021 net_addr_del: 10.15.187.71/24 dev tun0
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.873 2021 net_iface_mtu_set: mtu 1500 for tun0
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.873 2021 net_iface_up: set tun0 down
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.874 2021 Connected via tun
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.874 2021 LZO-ASYM init swap=0 asym=1
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.874 2021 Comp-stub init swap=0
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.875 2021 EVENT: CONNECTED europe3.vpn.airdns.org:443 (194.187.251.165) via /TCPv4 on
tun/10.15.187.71/ gw=[10.15.187.1/]
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.875 2021 Server has pushed its own DNS. Removing system DNS from network filter.
May 12 16:37:49 vpn-client hummingbird[366]: iptables: Bad rule (does a matching rule exist in that chain?).
May 12 16:37:49 vpn-client hummingbird[366]: Wed May 12 16:37:49.887 2021 System DNS 192.168.14.1 is now rejected by the network filter

 

[Staff 9972]

@air2157

Hello!

We should have spotted the problem.

The firewall is not the problem, apparently, but the fact that --persist-tun works fine when used as a Hummingbird option, while persist-tun as an OpenVPN directive causes the problem. We could reproduce the problem: when we have persist-tun merely as a profile directive, the tun interface goes down at the re-connection (as if the directive were ignored), but if --persist.-tun is added as an Hummingbird line option, then tun persistence is respected. Thank you for the report, the bug is now under investigation. Can you test with the option, as a cross-check?

Kind regards
 

[air2157 4]

I can confirm that adding --persist-tun to the command line prevents the link from failing after a SIGUSR2.

However, I'd like to make a few observations:

The suggestion that persist-tun is necessary for a SIGUSR2 restart isn't documented anywhere that I can see. The documentation simple states: "SIGUSR2: Reconnect (restart) the active VPN connection". (I can see the logic of needing persist-tun for SIGUSR1, but not for SIGUSR2.)

Requiring persist-tun for a restart of the connection is "unhelpful" for several reasons:

• First, AFAICT, it breaks compatibility with OpenVPN's use of SIGUSR1, which allows the possibility of restarting without persist-tun.
• Second, the whole point of the exercise for me was to pick up a new server from europe3.all.vpn.airdns.org. My tests indicate that this doesn't work using SIGUSR2, and the server address is unchanged.
• Third, is there actually a way to restart the tunnel and run the up / down scripts, just like SIGHUP does on OpenVPN? (Unfortunately, SIGHUP terminates the Hummingbird process. Why the divergence?)

 

[Staff 9972]

17 hours ago, air2157 said:

I can confirm that adding --persist-tun to the command line prevents the link from failing after a SIGUSR2.

Hello!

Thank you. The problem is in the OpenVPN3 profile parser unfortunately. We have completely rewritten the option parser but not the profile parser. Maybe we'll do it in the future, as the bug is there, but not before the 1.1.0 Suite release. Maybe in the meantime the bug will be fixed in the main branch, but yes, profile parser needs a deep rewrite, which is not a trivial job.

So, at the moment, you need to use persist-tun as an option, so it will be handled by our option parser and will work as expected.
 

Quote

The suggestion that persist-tun is necessary for a SIGUSR2 restart isn't documented anywhere that I can see. The documentation simple states: "SIGUSR2: Reconnect (restart) the active VPN connection". (I can see the logic of needing persist-tun for SIGUSR1, but not for SIGUSR2.)

Right. We'll document it, in the meantime remember it.
 

 

Quote

 

Requiring persist-tun for a restart of the connection is "unhelpful" for several reasons:

• First, AFAICT, it breaks compatibility with OpenVPN's use of SIGUSR1, which allows the possibility of restarting without persist-tun.

 

OpenVPN3 main branch in Linux fails any re-connection of any sort last time we tried, for a critical bug we fixed which messed up routing table. OpenPVN3 AirVPN handles re-connection with persist-tun only (otherwise the tun interface is brought down and never brought up again). We can't rule out that in the future we'll investigate this other failure too but it has low priority now because tun persistence during a re-connection is a feature that should be enforced for a good reason.

Anyway, as you can see bug fixes from the main branch proceed at a sustained pace in our fork, but bug discoveries in the main branch proceed quickly too. We can't humanly fix bugs which accumulated in a decade, or so, all at once, but we will do it one by one according to priorities. Please keep reporting and we'll keep fixing according to priorities.

About compatibility.... Compatibility with OpenVPN 2 servers is a high priority of ours and our latest OpenPVN3 AirVPN version is right now much more compatible than OpenVPN 3 main branch, but compatibility with choices on the client side we do not agree with may or may not be maintained (more on this below).
 

Quote

Second, the whole point of the exercise for me was to pick up a new server from europe3.all.vpn.airdns.org. My tests indicate that this doesn't work using SIGUSR2, and the server address is unchanged.

 
Re-connection means "re-connect to the same server". It does not mean disconnect, pick a new server, if it's different than the previous one connect to it otherwise repeat the server pick. Currently you can't reliably have any "randomization" with a re-connection, instead you can expect normally quite the opposite.

At the moment you don't have a way to efficiently pseudo-randomize connections from inside Hummingbird by sending it any signal, we're sorry.

 

Quote

Third, is there actually a way to restart the tunnel and run the up / down scripts, just like SIGHUP does on OpenVPN? (Unfortunately, SIGHUP terminates the Hummingbird process. Why the divergence?)

OpenVPN3 has never supported up / down scripts. We might suppose that, perhaps, the missing feature is due to security considerations. Up and down scripts have been historically the tool for exploits, for example privilege escalation, as they allow an attacker to run with root privileges her own script or binary pre-installed without root privileges.

Support to run external scripts or binaries from our library is currently not planned. Running external scripts from Bluetit is currently not planned as well, as Bluetit is a daemon: running any binary or script external to it is a practice which should be avoided when possible, as it enlarges the attack surface. Of course nothing prevents you to control Bluetit in ways which allow execution of your scripts and binaries when certain events occur. Developer guide will be published soon after we reach 1.1.0 stable release.

Hummingbird, Bluetit and Goldcrest handle signals, or any other thing, according to our logic and considerations, with no constraints coming from any OpenVPN 2 or OpenVPN 3 tradition.

For example, OpenVPN 3 has maintained and maintains several incompatibilities with OpenVPN 2 servers various versions, and we have decided to resolve them. In general, you can expect that OpenVPN 3 AirVPN library aims at maximum compatibility with OpenVPN 2 servers, while AirVPN programs Suite (Hummingbird, Goldcrest and Bluetit) are not tied to OpenVPN traditions, or to OpenVPN itself. In the future they might make use of protocols, libraries or kernel modules different than OpenVPN 3 AirVPN, of course.

SIGHUP to OpenVPN causes a hard re-start, while Hummingbird exits cleanly when it receives that signal..

Thank you all for your tests again, we have been working on a new Release Candidate since weeks ago, together with your directions and bug findings, and it is almost ready, stay tuned!

Kind regards