Thinking about what a 'VPN' solution is authenticating
When I wrote about the practical appeal of a mesh-capable VPN system, Walex left a comment that mentioned end to end IPsec. When I read the comment I had a reaction of 'that's not the same thing', and then I had to think about why I felt that way. Part of it is what you're authenticating when you use a 'VPN' like system, either mesh or otherwise, because there is actually a wide spread of answers.
Traditional VPN solutions are almost always theoretically authenticating people. Authenticating people is the only context where talking about such things as 'a MFA-protected VPN' really make sense; machines don't really have multiple factors. Of course the people being authenticated are using devices and machines, but we assume implicitly that these are single-user devices.
A non-MFA traditional VPN solution can also be used to authenticate machines, by creating and issuing an authentication token or an account for and to the machine, instead of to a person. You configure the authentication on the device and after that it works on its own. In practice non-MFA traditional VPNs are often doing this by default, because after the user sets your VPN up they'll have their device store the authentication token or remember their password.
A basic WireGuard deployment also works on what's basically device based authentication. Each endpoint (which is normally 'a device') needs an identity, and these identities are onerous enough to set up that you do it once and then don't touch it afterward. If you want to rotate identities, invalidate them, or stop accepting them until people re-authenticate somehow, you'll need to add some sort of system on top (eg). However, the process of issuing or registering WireGuard identities can be driven by people and tied to them, and if the devices are single-user devices, this comes almost as close to your WireGuard environment authenticating people as a traditional non-MFA VPN does.
(People might choose to type some sort of password every time they want to enable a traditional VPN, instead of having their device memorize it. There's no practical choice other than having your device memorize your WireGuard identity, and the default WireGuard clients make no attempt to store it encrypted in a way that requires a passphrase.)
Using a mesh-capable VPN system doesn't necessarily change this. Used one way, a mesh-capable VPN simply has multiple VPN 'servers', each of them acting as a gateway to different resources. However, you can use a mesh-capable VPN system to have servers talk to each other with tunneled traffic and good identity verification, and at this point you're authenticating (some) devices, not people. In some mesh-capable VPN systems, you can have a mixture of what's being authenticated, with some people and some machines.
(A traditional non-mesh VPN can be used this way as well, with one or more remote machines using the VPN to get connected to your internal resources. This is more secure than simply authorizing access through your firewall based on IP.)
IPsec is from a long ago world that more or less predates the idea that personal devices would be pervasive. As a result, standard IPsec more or less only authenticates machines, not people. To authenticate people you need to layer additional software on top, much as you need to with WireGuard.
If you're thinking of a mesh-capable VPN system that will primarily authenticate people, IPsec is sort of solving the wrong problem. It could be a component of a solution, but by itself it's normally working at the wrong layer. Much like WireGuard, it would need another layer of software on top, a layer that dealt with people and authenticating them.
What you need and are interested in depends on your situation. We certainly have a number of uses for authenticating machines (cf), while we definitely need and want a VPN that authenticates people (partly so that we can let them use our IPs).