Defguard 2.2 Release Alpha 1 is now available

This is an early alpha release, not meant for production use. Use it to test brand-new functionalities.

About this release

Until now, MFA on a location was a switch: on or off, internal or external. Defguard 2.2 makes it something you design: named flows built from ordered steps, each step holding the factors that may satisfy it.

Alpha 1 also brings FIDO2 security keys as a VPN factor, bulk actions in the Firewall module, correct DNS behaviour when several locations are connected at once, and a completely redesigned Mobile Client.

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.

Alpha 1 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, with the exception of FIDO2.

A user approving a desktop connection with biometrics, or connecting from the phone itself, sees the same product in both places. Try it through the Android beta in the Play Store, the iOS public test on TestFlight, or the bundles in the release assets.

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.

Use a FIDO2 hardware key as an MFA factor

Codes typed from a phone can be phished, and a growing number of security policies no longer accept them 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 or a Swissbit token.

Defguard 2.2 lets users register a FIDO2/WebAuthn key, the standard behind passkeys, in their profile as a passkey, naming each one and adding as many as they need, including the keys they already carry for Cisco Duo. Administrators add the FIDO2 Security Key factor to a flow and assign that flow to a location, on the desktop client only, as the mobile client cannot present it.

An engineer connecting to the production location touches the Swissbit key 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.

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.

Alpha 1 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.

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 test

Run the latest server components with the one-line script in pre-release mode. The Mobile Client is available through the Play Store beta, TestFlight and 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.