Fixing VPN Group Assignment in FortiGate: A DUO RADIUS Walkthrough

The Problem

A mid-market organization was struggling with VPN connectivity for users across two Active Directory domains. Some users could authenticate, others couldn't. The root cause was straightforward once we dug in: the FortiGate VPN configuration wasn't properly grouping users from both RADIUS sources.

The Setup

The customer had two RADIUS servers in play:

• DUO_RADIUS (primary domain)
• DUO_RADIUS_NewDomain (secondary domain for New Domain)

Both were feeding into the VPN gateway, but the firewall policies weren't consolidating those groups into a single usable assignment.

What We Did

Step 1: Create a unified user group

We created a new user group called DUO-VPN-ALL that explicitly added both RADIUS remote groups as members. This was the key move—instead of trying to manage policies against individual RADIUS groups, we had one canonical group that represented "everyone who should have VPN access."

Step 2: Update firewall policies

We then updated firewall policies to ensure they correctly referenced DUO-VPN-ALL instead of the individual RADIUS groups. This ensured consistent policy application across all VPN traffic.

Step 3: Validate connectivity

We tested with users from both domains:

• NewDomain domain user (user2): ✓ connected
• OriginalDomain domain user (user1): ✓ connected

Both successfully authenticated and got assigned the correct policies.

The Secondary Win

During the same session, we confirmed that a secondary Active Directory domain controller had been added to the DUO directory sync. That sync had completed successfully the day before, which meant RADIUS was pulling fresh group membership data. That timing helped explain why some of the earlier sporadic connectivity issues had resolved on their own.

The Takeaway

When you're managing VPN access across multiple RADIUS sources or AD domains, don't try to manage policies against individual remote groups. Create an intermediate local group that aggregates all your RADIUS sources, then build your policies around that. It's cleaner, easier to troubleshoot, and survives configuration changes better.

Where This Breaks in Production

This doesn't show up in single-domain environments.

It shows up when:

• Two separate AD domains are served by separate RADIUS servers behind the same FortiGate
• The standard FortiGate RADIUS config assumes one authentication namespace on one port — which works until a second domain is added
• Users from one domain authenticate successfully while users from the other domain fail with credential errors that don't clearly indicate a RADIUS routing problem

The failure mode is that the VPN works for some users and silently fails for others, and the error looks like a credential issue rather than a config routing issue.

If This Is Happening in Your Environment

Multi-domain VPN authentication failures like this are rarely what they look like at first.

They're usually a RADIUS routing or policy assignment issue that surfaces after a second domain or authentication tier is added to an environment that wasn't designed for it.

If your VPN authentication works for some users but not others after a domain change or RADIUS update, that's typically where we get brought in.

We don't rebuild from scratch — we fix and stabilize what's already there.

→ itccinc.com