Hummingbird "Weakness" using Network lock

[eburom 16]

Hi, some days ago I left my PC running and connected to the internet through AirVPN (using hummingbird). When I came back I found my computer downloading stuff with no VPN connection. The thing was that for some reason Hummingbird had crashed and, to my surprise, the Network lock didn't block the connection.
After some digging I saw that hummingbird was printing a log message saying it couldn't set the network lock up.
I guess it was my systems fault but hummingbird run as if nothing happened. but for a line in the logs, and it was almost impossible to notice.
There may be a good reason that I'm missing but from my point of view if I try to run it with the network lock on and the lock can not be activated then hummingbird should fail.

[Flx 76]

2 hours ago, eburom said:

Hi, some days ago I left my PC running and connected to the internet through AirVPN (using hummingbird). When I came back I found my computer downloading stuff with no VPN connection. The thing was that for some reason Hummingbird had crashed and, to my surprise, the Network lock didn't block the connection.

If this happened in Windows 10 you should not be surprised.
Please post the logs

[monstrocity 31]

3 hours ago, Flx said:

If this happened in Windows 10 you should not be surprised.
Please post the logs

Hummingbird only runs on Linux or macOS, but OP should have stated the OS and provided logs (if possible).

[Flx 76]

@monstrocityThank you for clarifying that. I prefer to craft my own systems and networks. not to have to rely on Eddie client etc. Thanks.

[Staff 10018]

@eburom

Can you please post complete log?

Kind regards
 

[eburom 16]

Agreed that I should have posted more detailed info, at least logs but it's not happening any longer.
By the way I was running Hummingbird 1.0.2 (x86-64 bit) on Arch Linux.

Just before closing the topic until it should happen again (and I can provide logs) I'd like to share a similar situation I was able to achieve by tricking the system:
The starting point was an up to date Arch Linux with no previous firewall rules set

# iptables-legacy -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Now hummingbird works like a charm, as I'm used to.

I tried removing all iptables binaries from /usr/bin and when I tried to run hummingbird I got:

Hummingbird - AirVPN OpenVPN 3 Client 1.0.2 - 4 February 2020

terminate called after throwing an instance of 'NetFilterException'
  what():  No usable firewall found on this system
Aborted (core dumped)

Pretty much what I would have expected.
So far so good, my next move was to try and trace what iptables calls hummingbird did by replacing the binaries by some other that would log the calls with their arguments and started getting some similar behavior to that of the original problem. It seems that hummingbird sets its rules through a call to iptables-legacy-restore and by replacing iptables-legacy-restore by a dummy executable script (tried exiting with exit code 0 and with exit code 1) I achieved a similar situation to the original one.
In this case hummingbird reports a very similar error to the one I got the other day but kept running with a minimal change to the loaded rules.

# iptables-legacy -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A OUTPUT -d 10.23.252.1/32 -j ACCEPT

I know this is something I tricked but I share it as a scenario in which hummingbird "detects" some errors when setting the network lock but keeps going any way.

Hummingbird - AirVPN OpenVPN 3 Client 1.0.2 - 4 February 2020

Fri May 15 20:55:48.560 2020 Starting thread
Fri May 15 20:55:48.560 2020 OpenVPN core 3.6.3 AirVPN linux x86_64 64-bit
Fri May 15 20:55:48.564 2020 Frame=512/2048/512 mssfix-ctrl=1250
Fri May 15 20:55:48.569 2020 UNUSED OPTIONS
3 [resolv-retry] [infinite]
4 [nobind]
5 [persist-key]
6 [persist-tun]
7 [auth-nocache]
8 [route-delay] [5]
9 [verb] [3]
10 [explicit-exit-notify] [5]
Fri May 15 20:55:48.569 2020 EVENT: RESOLVE
Fri May 15 20:55:48.569 2020 Network filter and lock is using iptables-legacy
Fri May 15 20:55:48.575 2020 Successfully loaded kernel module iptable_filter
Fri May 15 20:55:48.589 2020 Successfully loaded kernel module iptable_nat
Fri May 15 20:55:48.595 2020 Successfully loaded kernel module iptable_mangle
Fri May 15 20:55:48.601 2020 Successfully loaded kernel module iptable_security
Fri May 15 20:55:48.606 2020 Successfully loaded kernel module iptable_raw
Fri May 15 20:55:48.611 2020 Successfully loaded kernel module ip6table_filter
Fri May 15 20:55:48.626 2020 Successfully loaded kernel module ip6table_nat
Fri May 15 20:55:48.632 2020 Successfully loaded kernel module ip6table_mangle
Fri May 15 20:55:48.637 2020 Successfully loaded kernel module ip6table_security
Fri May 15 20:55:48.642 2020 Successfully loaded kernel module ip6table_raw
Fri May 15 20:55:48.645 2020 Network filter successfully initialized
Fri May 15 20:55:48.645 2020 Local IPv4 address 192.168.1.70
Fri May 15 20:55:48.645 2020 Local interface enp62s0u1u2
Fri May 15 20:55:48.645 2020 Local interface wlp2s0
Fri May 15 20:55:48.646 2020 Setting up network filter and lock
Fri May 15 20:55:48.646 2020 Allowing system DNS 127.0.0.1 to pass through the network filter
Fri May 15 20:55:48.646 2020 Adding IPv4 server 185.103.96.130 to network filter
Fri May 15 20:55:48.646 2020 ERROR: Cannot activate network filter and lock
Fri May 15 20:55:48.646 2020 Contacting 185.103.96.130:443 via UDP
Fri May 15 20:55:48.646 2020 EVENT: WAIT
Fri May 15 20:55:48.646 2020 net_route_best_gw query IPv4: 185.103.96.130/32
Fri May 15 20:55:48.646 2020 sitnl_route_best_gw result: via 192.168.1.1 dev enp62s0u1u2
Fri May 15 20:55:48.646 2020 net_route_add: 185.103.96.130/32 via 192.168.1.1 dev enp62s0u1u2 table 0 metric 0
Fri May 15 20:55:48.646 2020 Fri May 15 20:55:48.646 2020 Connecting to [185.103.96.130]:443 (185.103.96.130) via UDPv4
Fri May 15 20:55:48.704 2020 EVENT: CONNECTING
Fri May 15 20:55:48.704 2020 Tunnel Options:V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client
Fri May 15 20:55:48.705 2020 Peer Info:
IV_VER=3.6.3 AirVPN
IV_PLAT=linux
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO_STUB=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
UV_IPV6=yes
IV_GUI_VER=Hummingbird - AirVPN OpenVPN 3 Client 1.0.2
IV_SSL=mbed TLS 2.16.3

Fri May 15 20:55:48.801 2020 VERIFY OK : depth=1
cert. version     : 3
serial number     : 8C:D8:43:EF:E4:5F:20:03
issuer name       : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
subject name      : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
issued  on        : 2014-04-11 10:15:45
expires on        : 2024-04-08 10:15:45
signed using      : RSA with SHA1
RSA key size      : 4096 bits
basic constraints : CA=true

Fri May 15 20:55:48.801 2020 VERIFY OK : depth=0
cert. version     : 3
serial number     : EE
issuer name       : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
subject name      : C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Minkar, emailAddress=info@airvpn.org
issued  on        : 2016-12-28 14:11:24
expires on        : 2026-12-26 14:11:24
signed using      : RSA with SHA-512
RSA key size      : 4096 bits
basic constraints : CA=false
cert. type        : SSL Server
key usage         : Digital Signature, Key Encipherment
ext key usage     : TLS Web Server Authentication
Fri May 15 20:55:49.077 2020 SSL Handshake: TLSv1.2/TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
Fri May 15 20:55:49.077 2020 Session is ACTIVE
Fri May 15 20:55:49.077 2020 EVENT: GET_CONFIG
Fri May 15 20:55:49.077 2020 Sending PUSH_REQUEST to server...
Fri May 15 20:55:49.260 2020 OPTIONS:
0 [comp-lzo] [no]
1 [redirect-gateway] [ipv6] [def1] [bypass-dhcp]
2 [dhcp-option] [DNS] [10.23.252.1]
3 [dhcp-option] [DNS6] [fde6:7a:7d20:13fc::1]
4 [tun-ipv6]
5 [route-gateway] [10.23.252.1]
6 [topology] [subnet]
7 [ping] [10]
8 [ping-restart] [60]
9 [ifconfig-ipv6] [fde6:7a:7d20:13fc::1063/64] [fde6:7a:7d20:13fc::1]
10 [ifconfig] [10.23.252.101] [255.255.255.0]
11 [peer-id] [3]
12 [cipher] [AES-256-GCM]

Fri May 15 20:55:49.260 2020 PROTOCOL OPTIONS:
  cipher: AES-256-GCM
  digest: NONE
  ncp enabled: yes
  compress: LZO_STUB
  peer ID: 3
Fri May 15 20:55:49.260 2020 EVENT: ASSIGN_IP
Fri May 15 20:55:49.260 2020 VPN Server has pushed IPv4 DNS server 10.23.252.1
Fri May 15 20:55:49.264 2020 Setting pushed IPv4 DNS server 10.23.252.1 in resolv.conf
Fri May 15 20:55:49.264 2020 VPN Server has pushed IPv6 DNS server fde6:7a:7d20:13fc::1
Fri May 15 20:55:49.267 2020 Setting pushed IPv6 DNS server fde6:7a:7d20:13fc::1 in resolv.conf
Fri May 15 20:55:49.268 2020 net_iface_mtu_set: mtu 1500 for tun0
Fri May 15 20:55:49.268 2020 net_iface_up: set tun0 up
Fri May 15 20:55:49.269 2020 net_addr_add: 10.23.252.101/24 brd 10.23.252.255 dev tun0
Fri May 15 20:55:49.269 2020 net_addr_add: fde6:7a:7d20:13fc::1063/64 dev tun0
Fri May 15 20:55:49.269 2020 net_route_add: 0.0.0.0/1 via 10.23.252.1 dev tun0 table 0 metric 0
Fri May 15 20:55:49.269 2020 net_route_add: 128.0.0.0/1 via 10.23.252.1 dev tun0 table 0 metric 0
Fri May 15 20:55:49.269 2020 net_route_add: ::/1 via fde6:7a:7d20:13fc::1 dev tun0 table 0 metric 0
Fri May 15 20:55:49.269 2020 net_route_add: 8000::/1 via fde6:7a:7d20:13fc::1 dev tun0 table 0 metric 0
Fri May 15 20:55:49.270 2020 Connected via tun
Fri May 15 20:55:49.270 2020 LZO-ASYM init swap=0 asym=1
Fri May 15 20:55:49.270 2020 Comp-stub init swap=0
Fri May 15 20:55:49.270 2020 EVENT: CONNECTED 185.103.96.130:443 (185.103.96.130) via /UDPv4 on tun/10.23.252.101/fde6:7a:7d20:13fc::1063 gw=[10.23.252.1/fde6:7a:7d20:13fc::1]
Fri May 15 20:55:49.270 2020 Server has pushed its own DNS. Removing system DNS from network filter.
iptables: Bad rule (does a matching rule exist in that chain?).
Fri May 15 20:55:49.273 2020 System DNS 127.0.0.1 is now rejected by the network filter
 

[Staff 10018]

@eburom

Last test has showed that Hummingbird behavior is correct. Of course we can discuss ad nauseam whether an error of this kind should cause Hummingbird to exit completely or not: shall we consider the superuser responsible for his/her actions and trust that he/she does not ignore error messages, or shall we consider him/her inept for his/her role?

However, your previous report should be investigated if the issue re-occurs. That, indeed, shows an unexpected outcome, but as long as you can't reproduce it we can't do anything (we could not manage to reproduce it and it never came out during alpha, beta, RC testing...).

Kind regards
 

[eburom 16]

Agreed, I'm not blaming hummingbird for not protecting against any malicious superuser action. I was just doing what I could to bring a similar situation back.
About ignoring the log output.. well I usually run it as a service so I don't really pay attention to the logs until something works wrong. Bad practice? could be.

Yes hummingbird was sure running fine but I was surprised that it would stop running for some network lock errors but not for others, even it detects them. I'm almost certain that the original situation was due  to a bad behavior in my system, just thought that hummingbird could have stopped it from happening. Again, I'm not sure that should be hummingbird's job.

Anyway, my normal setup doesn't have an empty iptables rules from the start so this shouldn't be a big problem. I hope this thread serves as a heads up for people to read the logs when they run it.

Thanks for the replies.