AirVPN-Suite: Handling of internet connection loss

[snrtd 0]

Whenever I lose internet connection while I’m connected to a VPN server (by laptop suspend, ISP-side reconnection, router reboot ...), I would expect bluetit to restore the VPN connection when internet connection is available again. However, it fails to restore proper connectivity.

I’m using the 2.0 preview with wireguard, as well as 1.3.0 with openvpn3 on another machine. The issue applies to both.

Here’s what happens with version 2.0 (from the last failed reconnection attempt up to successful reconnection when internet connection was available again):

Dec 24 04:35:10 tp2 bluetit[12156]: Reconnecting VPN server
Dec 24 04:35:10 tp2 bluetit[12156]: Stopping WireGuard connection
Dec 24 04:35:10 tp2 bluetit[12156]: Disabling WireGuard network interface tun0
Dec 24 04:35:10 tp2 bluetit[12156]: WireGuard network interface tun0 successfully disabled
Dec 24 04:35:10 tp2 bluetit[12156]: WireGuard successfully disconnected
Dec 24 04:35:10 tp2 bluetit[12156]: Waiting 3 seconds before reconnecting
Dec 24 04:35:10 tp2 bluetit[12156]: Setting up WireGuard network interface tun0
Dec 24 04:35:10 tp2 bluetit[12156]: Allowing IPv4 0.0.0.0/0
Dec 24 04:35:10 tp2 bluetit[12156]: WireGuard end point set to IPv4 213.152.187.199, port 1637
Dec 24 04:35:10 tp2 bluetit[12156]: Successfully added WireGuard device tun0
Dec 24 04:35:10 tp2 bluetit[12156]: WireGuard interface tun0 set to IPv4 10.191.147.48/32
Dec 24 04:35:10 tp2 bluetit[12156]: WireGuard interface tun0 successfully configured
Dec 24 04:35:10 tp2 bluetit[12156]: MTU WireGuard network interface tun0 set to 1320
Dec 24 04:35:10 tp2 bluetit[12156]: WireGuard network interface tun0 successfully initialized and ready
Dec 24 04:35:10 tp2 bluetit[12156]: Successfully initialized WireGuard device tun0
Dec 24 04:35:10 tp2 bluetit[12156]: Connected to AirVPN server Alphard, Alblasserdam (Netherlands) (WireGuard)
Dec 24 04:35:12 tp2 bluetit[12156]: WireGuard handshaking timeout. Trying to recconnect VPN.
Dec 24 04:35:12 tp2 bluetit[12156]: Reconnecting VPN server
Dec 24 04:35:12 tp2 bluetit[12156]: Stopping WireGuard connection
Dec 24 04:35:12 tp2 bluetit[12156]: Disabling WireGuard network interface tun0
Dec 24 04:35:13 tp2 bluetit[12156]: WireGuard network interface tun0 successfully disabled
Dec 24 04:35:13 tp2 bluetit[12156]: WireGuard successfully disconnected
Dec 24 04:35:13 tp2 bluetit[12156]: Waiting 3 seconds before reconnecting
Dec 24 04:35:13 tp2 bluetit[12156]: Setting up WireGuard network interface tun0
Dec 24 04:35:13 tp2 bluetit[12156]: Allowing IPv4 0.0.0.0/0
Dec 24 04:35:13 tp2 bluetit[12156]: WireGuard end point set to IPv4 213.152.187.199, port 1637
Dec 24 04:35:13 tp2 bluetit[12156]: Successfully added WireGuard device tun0
Dec 24 04:35:13 tp2 bluetit[12156]: WireGuard interface tun0 set to IPv4 10.191.147.48/32
Dec 24 04:35:13 tp2 bluetit[12156]: WireGuard interface tun0 successfully configured
Dec 24 04:35:13 tp2 bluetit[12156]: MTU WireGuard network interface tun0 set to 1320
Dec 24 04:35:13 tp2 bluetit[12156]: WireGuard network interface tun0 successfully initialized and ready
Dec 24 04:35:13 tp2 bluetit[12156]: Successfully initialized WireGuard device tun0
Dec 24 04:35:13 tp2 bluetit[12156]: Connected to AirVPN server Alphard, Alblasserdam (Netherlands) (WireGuard)
Dec 24 04:37:06 tp2 bluetit[12156]: Updating AirVPN Manifest
Dec 24 04:37:06 tp2 bluetit[12156]: Trying connection to AirVPN bootstrap server at http://63.33.78.166
Dec 24 04:37:07 tp2 bluetit[12156]: AirVPN Manifest successfully retrieved from server

Apparently the bootstrap server is reachable (if the log is to be believed ... notice how it says connected at 04:35:10 when it really isn’t). However, at this stage I have to manually reset the connection by killing and restarting goldcrest to get internet connectivity back.

Here’s what happens when I do that:

Dec 24 08:05:34 tp2 bluetit[12156]: Stopping WireGuard connection thread
Dec 24 08:05:34 tp2 bluetit[12156]: Stopping WireGuard connection
Dec 24 08:05:34 tp2 bluetit[12156]: ERROR: cannot delete route (RTNETLINK answers: No such process
                                    )
Dec 24 08:05:34 tp2 bluetit[12156]: ERROR: cannot delete route (RTNETLINK answers: No such process
                                    )
Dec 24 08:05:34 tp2 bluetit[12156]: ERROR: cannot delete route (RTNETLINK answers: No such process
                                    )
Dec 24 08:05:34 tp2 bluetit[12156]: Removed route IPv4 213.152.187.199/32 via 192.168.1.1 dev wlan0

The error only appears when internet connection had been lost.
The equivalent error with 1.3.0:

Dec 24 08:04:26 zb bluetit[314529]: Stopping OpenVPN3 connection thread
Dec 24 08:04:26 zb bluetit[314529]: Connection statistics updater thread finished
Dec 24 08:04:26 zb bluetit[314529]: net_route_del: 128.0.0.0/1 via 10.7.62.1 dev tun1 table 0 metric 0
Dec 24 08:04:26 zb bluetit[314529]: net_route_del: 0.0.0.0/1 via 10.7.62.1 dev tun1 table 0 metric 0
Dec 24 08:04:26 zb bluetit[314529]: net_route_del: 213.152.187.202/32 via 192.168.1.1 dev enp2s0 table 0 metric 0
Dec 24 08:04:26 zb bluetit[314529]: sitnl_send: rtnl: generic error: No such process (-3)
Dec 24 08:04:26 zb bluetit[314529]: net_addr_del: 10.7.62.230/24 dev tun1
Dec 24 08:04:26 zb bluetit[314529]: net_iface_mtu_set: mtu 1500 for tun1
Dec 24 08:04:26 zb bluetit[314529]: net_iface_up: set tun1 down
Dec 24 08:04:26 zb bluetit[314529]: Error while executing NetlinkRoute4(add: 0) enp2s0: -3

If I’m reading this correctly it seems like the routing table is lost while having no internet connection (even if the interface stays up) and bluetit is unaware of that.

[Flx 76]

6 hours ago, snrtd said:

AirVPN bootstrap server at http://63.33.78.166

Wasn't this supposed to be https?
@Staff FAQ the answer below. Thx 

[Staff 9972]

@snrtd

Hello!

Thank you, we are going to verify and look into the issue.

@Flx

HTTP is correct, the flow is encrypted inside HTTP. This solution offers a few advantages in specific networks, mainly corporate, school, college networks, where HTTPS is not accepted if you don't install root certificates (usually aimed at traffic inspection by MITM attacks by the college, corporate, school networks which want to monitor all the traffic content of their employees/students/teachers). In this way your credentials and AirVPN certificates/keys are protected even when your machine is compromised by fake root certificates.

The method can also bypass some other blocks against HTTPS. The disadvantage is that if you're in a network which rejects HTTP completely or blocks HTTP with direct IP addresses (instead of names) then the Suite or Eddie fails to contact the bootstrap servers by default (but we offer custom bootstrap servers to be added in the run control file).

Kind regards