== I like WireGuard partly because it doesn't have 'sessions' I like [[WireGuard https://www.wireguard.com/]] for any number of reasons, both on a technical level and on the pragmatic level of it working well. One of the pragmatic things I like about it is that at the level of the user experience, it doesn't have the idea of 'sessions' the way at least OpenVPN and L2TP do. The problem with sessions is that an established session can be dropped or broken, and this can happen for relatively mysterious reasons (at least as the person using the VPN sees it). When a session is severed this way, software must established a new connection. Often this process is user visible and causes issues like long-running TCP connections to be broken (ie, your SSH logins). Sometimes one end thinks the session is dead and the other end doesn't realize this, so your activity just disappears into the void until either your software notices (and establishes a new connection) or you turn your VPN off and on again to do it by hand. With WireGuard, you can have logical connections that you turn on or off in your configuration system of choice, but this is purely a user interface issue. [[The underlying protocol is connection-less https://www.wireguard.com/protocol/]] and there's no session to break. If the underlying network path is interrupted for a while, neither end of the WireGuard connection will get upset. Packets will get lost for a while, then start getting delivered again, and any long-running TCP connections that break will break for natural reasons that the connection itself timed out. How WireGuard works even lets you move one end between networks without having things explode ([[I've gone through this ../linux/WireGuardBehindNAT]]). The practical result is that a WireGuard connection is likely to be quite resilient, and if it isn't the problem will be pretty clearly in the network path between the two endpoints. Even if the network path is flaky, a WireGuard connection may simply be slow. Meanwhile, OpenVPN and L2TP sessions seem to break if you sneeze on them. Another thing that helps this out is that WireGuard's connection-less nature pushes strongly toward static IP address assignment for the clients. I'm not sure it's completely required, but [[it's certainly what the tools want you to do ../linux/WireGuardAllowedIPs]]. With static IP address assignment as the default, a given client will always have the same IP if it has to re-handshake and will go on to naturally handle and continue ongoing traffic to it. With more session oriented VPN protocols, a client may well get a different IP when it re-establishes a new session and then generally all of your old TCP (and UDP) connections are intrinsically dead. PS: The flipside of this session-less nature is that you need a separate WireGuard identity (ie a client configuration) for each device someone wants to use, since two devices can't share a WireGuard identity at once. Other VPN protocols can potentially allow this.