FIDO2 hardware keys MFA for WireGuard® with multi-step MFA flows

About this release

Defguard 2.2 adds FIDO2 hardware security keys, such as a YubiKey, as an MFA factor for WireGuard® connections. The key works inside the new MFA flows, which make MFA something you design: named flows built from ordered steps, each step holding the factors that may satisfy it. Assign a flow to a location, and its tunnel opens only after the last step succeeds.

The redesigned Mobile Client takes part in those flows both as a factor and as a connecting client. Users can also set up MFA from the desktop client after enrolment, without enrolling again.

Bulk actions in the Firewall module, correct DNS behaviour when several locations are connected at once, control over the client MTU and the Windows interface metric, and bulk enrolment tokens for Active Directory are also part of this release.

Use a FIDO2 hardware key as an MFA factor

An authenticator app works from a secret that can be copied to another device, and a growing number of security policies ask for phishing-resistant MFA for privileged access. Defguard has so far answered that with biometric approval through the mobile app, which still rests on the user’s phone rather than on a hardware key such as a YubiKey.

Defguard 2.2 lets users register a FIDO2 key in the Desktop Client, naming each one and adding as many as they need. Administrators add the FIDO2 Security Key factor to a flow and assign that flow to a location. Users then present the key on their desktop, or hold it against their phone over NFC in the mobile client.

An engineer connecting to the production location touches the YubiKey in their laptop instead of reaching for a code. A second key, registered as a backup, keeps a lost one from turning into a locked-out user.

More reading: FIDO2 hardware security keys as a VPN MFA/2FA factor

Multi-step configurable MFA methods

One MFA setting for a whole location forces the same answer everywhere: the same proof for the printer network and for the production database. Administrators who wanted a stronger requirement on one location, or a fallback for users without a given factor, had nowhere to put it.

Defguard 2.2 introduces the MFA flow: a named, ordered list of steps, where each step holds the factors allowed to satisfy it: authenticator app, email code, external ID provider, FIDO2 security key, the mobile client or biometrics. The user proves one factor per step, the tunnel comes up only after the last step succeeds, and a flow written once can be assigned to any number of locations.

Give the office network a single step with an authenticator app and an email code as alternatives, so nobody is locked out for lacking one of them. Give the production location two steps, because there you genuinely want a second proof.

The Open Source plan covers one flow with a single step. More than one flow, more than one step and the External ID Provider factor need Business, and group-level MFA overrides on a location need Enterprise.

More reading: Multi-step MFA/2FA flows for WireGuard® VPN locations

Completely redesigned Mobile Client

The desktop client was rebuilt in 2.1, which left the mobile app looking like a different product. Users moving between the two met two different interfaces for the same job.

Defguard 2.2 ships a Mobile Client redesigned to match the rest of the refreshed Defguard family. It takes part in the new MFA flows both as a factor and as a connecting client, including FIDO2 security keys over NFC.

A user approving a desktop connection with biometrics, or connecting from the phone itself, sees the same product in both places. Download it from Google Play or the App Store, or use the bundles in the release assets.

More reading: A redesigned Mobile Client for iOS and Android

Set up MFA after enrolment

Until now, a user who needed a factor they had not set up had to be enrolled again. Defguard 2.2 changes that: when a location needs an MFA method the user has not set up, the desktop client shows Configure MFA in place of Connect, and the user sets it up in the application.

The user confirms the change with a factor they already have and can pick which one. A user with no factors yet confirms with an email code. The instance stays enrolled throughout, so nothing has to be removed and added again.

More reading: Set up MFA/2FA from the Desktop Client after enrollment

Bulk actions for the Firewall module

Firewall rules, destinations and aliases could only be handled one object at a time. A rule set of any size turned an ordinary cleanup into an afternoon of repetitive clicking.

Defguard 2.2 lets you select entries together in the table views and act on them in a single operation. The same applies to rules, destinations and aliases alike.

Retiring a decommissioned subnet means selecting its rules and removing them in one action. Nothing is left half-finished, so the policy never sits in an inconsistent state.

Handling multiple locations with DNS configuration connected simultaneously

Multi-location connectivity worked at the networking level, but DNS did not: Defguard wrote a flat nameserver and search configuration that cannot scope resolution per interface. On Linux with systemd-resolved several interfaces competed as the DNS default route, and on Windows adapter-level suffixes produced a similar ambiguity.

Defguard 2.2 now applies each location’s own resolvers and domains side by side. Queries reach the resolver that owns the domain instead of whichever interface happened to win.

A contractor connected to two client sites at once resolves internal hostnames from both. The usual workaround, disconnecting one location to reach the other, is no longer needed.

Custom MTU for the client apps

A packet size that is too large for the network can leave some websites loading slowly or not at all, and one reported case involved a Starlink connection. Until now, the alternatives were lowering the MTU on the firewall’s WAN port or on a router at the client site.

Defguard 2.2 lets administrators set a custom MTU that the client apps apply. The original request also asked for other WireGuard settings, which are not covered by this release.

WireGuard interface metric on Windows

Windows gave the WireGuard adapter a very low interface metric, so the VPN was preferred for all outbound traffic, including DNS. With split DNS, that overrode local resolvers such as a local AdGuard instance.

Defguard 2.2 makes the interface metric configurable, so the VPN no longer has to win every DNS query on Windows.

Bulk enrolment tokens for Active Directory

The auto-provisioning flow for Windows environments wrote each user’s enrolment token into Active Directory with a PowerShell script.

Defguard 2.2 does the same thing from the admin UI as a bulk action: you select the users and choose the Active Directory field that should receive the token. The auto-provisioning guide describes the rest of the setup.

Client compatibility

Multi-step flows are new, so clients older than 2.2.0 cannot present them. A location whose flow an older client cannot handle is not sent to that client at all, and simply does not appear until it is updated.

Older clients still connect to flows that have an equivalent in the pre-2.2 model: a single step holding internal factors, or a single step holding External ID Provider alone. Newer clients always work with older servers, so client applications can be updated first.

Check the client vs server feature compatibility matrix before upgrading a server ahead of your fleet.

How to deploy

Run the latest server components with the one-line script, or follow the upgrade guide for an existing instance. The Mobile Client is available on Google Play, the App Store and in the release assets.

Feedback

We want as much feedback as possible, so open a GitHub discussion or report missing features and bugs as issues. The full changelog is on GitHub.