Implement new connection verification approach

[teon]

Context

Due to WireGuard (and UDP protocol) nature, it's impossible to know whether the connection: actually has been initiated, if it's still "ongoing" or if it's lost, etc.
This confuses users and imposes some difficulties to the IT/Management staff when debugging (if the connection actually works? or do we have ACL problem? etc..).
Also - we have problem with our statistics due to this fact (we estimate the connection inactivity and then decide if the connection is down when there is inactivity for X).

New feature proposal

But we could introduce an optional feature, that our customers would enable like connection verification with gateway ping and gateway communication (about disconnecting, etc) over only the vpn networks.

This approach would also provide some possibilities like: inform from the client that it's disconnecting, etc.

This will for sure not resolve all issues like the connection will be lost for some time (changing networks, etc.) or the fact that the Mobile client can't connect in the background with our services non stop... but will be a remedy for some problems.

Any ideas, preferences, comments welcome.

[wojcik91]

From a related proposal in client repo:

Context

A constant pain point for our users seems to be that interface state is often incorrect in case of any non-client issues.
While the underlying problem is usually some additional functionality we've build on top of wireguard (like MFA, ACL or DNS management) it's not apparent to the user and debugging is made even harder because we detect issues based on interface stats with a 5 minute delay which muddies the waters.

Proposal

A simple solution would be to leverage the fact that each client (desktop & mobile) is connected to the gateway and just ping it periodically. The gateway address is known (although could cause issues if changed) and we can prevent blocking it at ACL level by adding a firewall exception.

Instead of just disconnecting the interface we can introduce a third state (like "no internet connectivity" on mobile devices; include a warning icon or something) and leave reconnecting to the user.

In the future we might consider keeping a TCP connection open to detect connection status from both ends.

[wojcik91]

In theory the gateway could also be used to verify if a peer is reachable (by a ping through the VPN tunnel) which would improve detection on the core side.

If we move away from relying on just stats to determine connection status we could also actually store "VPN sessions" and pre-process peer stats instead of using an expensive DB view.

[georgivalentinov]

Adding a case that may be related to this issue, or at least how it's being handled on the client side:

This is a screenshot of a DefGuard client that's currently connected, but due to past disconnect events, still has such events accumulated visually. So it easily confuses and adds ambiguity on whether we're currently connected and if there's an ongoing issue or not.

[teon]

@georgivalentinov it's on the roadmap for the next release - please follow this issue: DefGuard/client#425