Leaderboard

If you were connected the whole time, yes. All traffic is routed through the AirVPN server regardless according to the kernel routing table (in a command prompt or PowerShell, enter route print to see what I mean). For torrenting it's even sufficient to connect to AirVPN and bind to the VPN interface in the torrent client. NetLock is for those who don't want any app to access the internet outside the tunnel. By the way, they're not the same features: One tells the client which interface is to be used explicitly (so it's only for the torrent client), the other adds firewall rules to actively block outgoing connections to the world if not going through the tunnel (so it's for all apps on the PC, including the torrent client). I think they're not standing in each other's way if you want to use both, it's more like a redundancy.

MX-Linux release 19 features Eddie on their Stable Repo, meaning you can install it with one click. Actually Mx Linux is -imho- one of the best distro out there: easier than mint, lighter than xubuntu, very stable. But what makes it great is the devs behind it, very quick to listen to users improve things (like for example, including eddie on their repo, based on a user request). I am not affiliated at all with it, I am just a very happy user.

This message does not indicate lost packages but packages which seem retransmitted and are therefore dropped, causing the connection outages OP mentions – that is, if enough packets are being missed for the apps to "notice" something is not right. The smaller your bandwidth the more probable outages become. Since TCP guarantees a strict order and retransmission upon lost packets, the message, by principle, can never be seen there. But! The problem introduces something called the TCP-over-TCP problem and starts occuring when making connections in the browser, in apps, etc. over TCP while connected with AirVPN over TCP. While true, I tend to dig deeper and find out why they appear in the first place.

I am getting those errors too every now and then, but they normally shouldn't lead to a complete disconnection of the VPN. Packet loss over UDP is very common, unfortunately. It can occur due to an improperly configured MTU size and / or a bad line to the destination server. You can however suppress those erros by adding "mute-replay-warnings" under "OVPN directivies" in the Eddie client.

It only happens with UDP. TCP works around this problem. Usually it means that something on your line is doing Quality of Service "optimizations" like reordering or rerouting packets on the fly. DOCSIS (TV cable)-based internet access is known for that, but I'd look in your own network first and look at firewalls you might be using on your PC or the router. Some of the latter have things like "UDP flood protection" or "QoS" on.