I'm on my BTGuard VPN, and just randomly got a connection denial popup from Little Snitch. The notes from the entry in LS is:

On May 29, 2019, vpn.btguard.com tried to establish an incoming connection to openvpn. The request was denied automatically because this kind of connection cannot be delayed.


It's probably something like a stray packet from the previous time you were connected. For example, the OpenVPN client restarted, but the server still tried sending data over the previous session.

OpenVPN (by default, and in BTGuard's configuration) runs over UDP, which is a stateless transport protocol in which there are no explicit 'establish connection' or 'disconnect' packets, no sequence numbers, nothing except a pair of port numbers.

  • In TCP, hosts and firewalls start tracking a connection as soon as they see the SYN (handshake) packets. But in UDP, because there is no 'connect' packet of any sort (just data packets), firewalls simply start tracking "connections" after any packet they see.

  • In TCP, hosts and firewalls forget a connection as soon as they see the FIN (disconnection) packets. But in UDP, because there is no 'disconnect' packet of any sort, firewalls must use timeouts to expire old "connections" (e.g. the entry is removed whenever it's idle for 60sec or 180sec or 10min or similar).

  • Programs such as OpenVPN of course may have 'connect' / 'disconnect' commands in their application-layer protocol, but a firewall knows nothing about that – it only sees UDP with some data inside.

So what sometimes happens is:

  1. Either OpenVPN restarts/exits and the firewall forgets all entries associated with the old process, or the VPN connection goes idle for so long that the firewall forgets about it due to reaching the expiry time.

  2. However, the BTGuard server hasn't received the OpenVPN "disconnect" packet, and it hasn't forgotten the connection due to timeout either, so it tries sending some data back to you over the old session.

  3. The firewall sees the incoming packet and has no way of knowing whether it's a new "connection" or whether it belongs to a previously established one. (And it has no way of knowing whether it was originally established outwards or inwards, either.)

    Because the firewall doesn't remember this port pair (due to forgetting it in part 1), it just assumes it has to be new. And because it's an incoming packet, the firewall shows a warning about "incoming connection".

It's a guess but it's a decent guess.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.