NSE6 Part 7: FortiSwitch 802.1X, MAC Authentication Bypass, and Port Security

802.1X is where the FortiSwitch and FortiAuthenticator exam tracks intersect. The switch acts as the authenticator (the gatekeeper), FortiAuthenticator acts as the authentication server (the authority), and the endpoint acts as the supplicant (the entity proving its identity). Get one of those three roles wrong in your mental model and the troubleshooting questions on the exam will trip you up.

---

802.1X Concepts

The three roles

Role	Device	Responsibility
Supplicant	Endpoint (PC, phone, printer)	Provides credentials via EAP
Authenticator	FortiSwitch	Relays EAP between supplicant and auth server; enforces access decision
Authentication server	FortiAuthenticator	Validates credentials; returns Access-Accept or Access-Reject

The FortiSwitch does not validate credentials. It passes EAP messages from the endpoint to FortiAuthenticator via RADIUS (EAP over RADIUS, RFC 3579) and enforces the decision. This is called EAP pass-through.

EAP methods

Method	Credential type	Server cert required	Client cert required
EAP-MD5	Password	No	No
EAP-TLS	Certificate	Yes	Yes
PEAP-MSCHAPv2	Password	Yes	No
EAP-TTLS/PAP	Password	Yes	No

Exam focus:

• EAP-TLS is the most secure (mutual certificate authentication) but requires client certificates issued by a CA — FortiAuthenticator as CA (Part 4) is directly relevant here.
• PEAP-MSCHAPv2 is the most common enterprise deployment: server-side cert only, users authenticate with their AD password.
• EAP-MD5 is not recommended (no server authentication, vulnerable to MITM) — know it exists but is exam-deprecated.

EAPOL frame exchange

1. Endpoint connects to a port → FortiSwitch sends EAP-Request/Identity
2. Endpoint responds with EAP-Response/Identity (username)
3. FortiSwitch wraps this in a RADIUS Access-Request → sends to FortiAuthenticator
4. FortiAuthenticator challenges (EAP-Challenge) → FortiSwitch relays back to endpoint
5. Endpoint provides credentials → relayed to FortiAuthenticator
6. FortiAuthenticator returns Access-Accept (with optional VLAN attributes)
7. FortiSwitch moves the port to the authenticated VLAN and starts forwarding

---

Configuring 802.1X on FortiSwitch (FortiLink Managed Mode)

Step 1 — RADIUS server on FortiGate

The RADIUS server object on FortiGate is what FortiSwitch uses to communicate with FortiAuthenticator:

config user radius
  edit "FAC-RADIUS"
    set server "10.0.0.10"
    set secret "SharedSecret123"
    set auth-type auto
  next
end

Step 2 — 802.1X security policy

config switch-controller security-policy 802-1X
  edit "corporate-dot1x"
    set auth-fail-vlan enable
    set auth-fail-vlanid 99          # VLAN for failed auth
    set guest-vlan enable
    set guest-vlanid 50              # VLAN for devices that don't respond to EAP
    set open-auth disable
    set radius-timeout-overwrite enable
    set mac-auth-bypass enable       # Enable MAB fallback (covered below)
    set eap-passthrough enable
  next
end

Step 3 — Apply policy to port profile

config switch-controller initial-config template
  edit "access-profile"
    set 802-1x "corporate-dot1x"
  next
end

Or directly on a port:

config switch-controller managed-switch
  edit "S524DF4K15000024"
    config ports
      edit "port5"
        set security-policy "corporate-dot1x"
      next
    end
  next
end

---

Dynamic VLAN Assignment

Dynamic VLAN is the mechanism that lets FortiAuthenticator return a different VLAN for each user or group — no static port-to-VLAN mapping needed.

RADIUS attributes required

When FortiAuthenticator returns Access-Accept, it must include all three of these attributes together:

Attribute	Value
Tunnel-Type (64)	13 (VLAN)
Tunnel-Medium-Type (65)	6 (IEEE 802)
Tunnel-Private-Group-ID (81)	VLAN ID as string (e.g., “100”)

All three must be present. If any one is missing, FortiSwitch ignores the VLAN assignment and uses the port’s static native VLAN.

Configuring on FortiAuthenticator

Authentication > RADIUS Service > Attribute Assignments

User group: Engineering-Staff
Return attributes:
  Tunnel-Type = 13
  Tunnel-Medium-Type = 6
  Tunnel-Private-Group-ID = 100

User group: Finance-Staff
Return attributes:
  Tunnel-Type = 13
  Tunnel-Medium-Type = 6
  Tunnel-Private-Group-ID = 200

Now an engineering employee connecting anywhere on the FortiSwitch fabric lands in VLAN 100, and a finance employee in VLAN 200, regardless of which port they plug into.

Guest VLAN and auth-fail VLAN

Guest VLAN: Assigned to a port when no EAP response is received within the timeout. The endpoint either doesn’t have an 802.1X supplicant, or the supplicant is disabled. The guest VLAN gives limited connectivity (internet-only, or registration portal).

Auth-fail VLAN: Assigned when EAP authentication actively fails (wrong password, revoked certificate). Distinct from guest VLAN — a failed auth is a different risk profile to a device with no supplicant.

Both VLANs are defined in the 802.1X security policy (see config above).

---

MAC Authentication Bypass (MAB)

MAB handles devices that cannot run an 802.1X supplicant: printers, IP cameras, legacy industrial controllers, VoIP phones without 802.1X support.

How MAB works

1. 802.1X times out (no EAP response from the device).
2. FortiSwitch sends a RADIUS Access-Request with:
   • User-Name = device’s MAC address (lowercase, no separators, e.g. aabbccddeeff)
   • User-Password = MAC address (same value, as a simple shared secret)
3. FortiAuthenticator looks up the MAC in its MAC filter list or the device MAC list.
4. If found: Access-Accept with the appropriate VLAN attributes.
5. If not found: Access-Reject → port falls to auth-fail VLAN.

MAB database on FortiAuthenticator

Authentication > MAC Address Filter

Each entry: MAC address + optional group assignment. The group determines what RADIUS attributes are returned (VLAN, etc.).

Import in bulk via CSV if you have hundreds of devices. Many organisations export MACs from their DHCP server and import them into FAC for initial population.

MAB order

Default behaviour: 802.1X is attempted first; MAB kicks in only after the 802.1X timeout:

config switch-controller security-policy 802-1X
  edit "corporate-dot1x"
    set mac-auth-bypass enable
    set open-auth disable
  next
end

The 802.1X timeout is set by radius-timeout-overwrite — if the RADIUS server takes too long, the port goes to guest VLAN while MAB is pending.

---

Re-authentication and Session Timeout

Once a device authenticates, the session can be configured to re-authenticate periodically:

config switch-controller security-policy 802-1X
  edit "corporate-dot1x"
    set radius-timeout-overwrite enable
    set authserver-timeout-period 30   # seconds to wait for RADIUS response
  next
end

The RADIUS Session-Timeout attribute (attribute 27) can be returned in the Access-Accept to override the local re-auth timer. This lets FAC drive session length based on user group.

---

Port Security — Sticky MAC

Sticky MAC learning locks a port to the first MAC address(es) that appear on it. If a different device is plugged in, the violation action triggers.

config switch-controller managed-switch
  edit "S524DF4K15000024"
    config ports
      edit "port5"
        set port-security enable
        set sticky-mac enable
        set mac-violation-action restrict   # log + drop new MACs (port stays up)
        # or:
        set mac-violation-action shutdown   # disable port immediately
        # or:
        set mac-violation-action replace    # replace old sticky MAC with new one
      next
    end
  next
end

Exam note: restrict keeps the port up but denies frames from unauthorised MACs. shutdown puts the port in err-disable state, requiring admin intervention to re-enable. replace is essentially no security — it just updates the sticky MAC.

MAC limit

Limit the total number of MAC addresses a port can learn:

config switch-controller managed-switch
  edit "S524DF4K15000024"
    config ports
      edit "port5"
        set max-frame-size 9000
        # mac-limit is set in the port security config
      next
    end
  next
end

Useful for access ports where more than one MAC appearing (device + a rogue switch plugged in) is a security concern.

---

CoA — Change of Authorization

CoA (RFC 5176) allows FortiAuthenticator or FortiNAC to push a mid-session change to a FortiSwitch port without requiring re-authentication from the endpoint.

Two CoA message types:

Message	Effect
CoA-Request	Change RADIUS session attributes (e.g., change VLAN ID)
Disconnect-Request (DM)	Terminate the session — forces re-authentication

Use cases:

• FortiNAC compliance failure: Device was in VLAN 100, failed a compliance scan, FortiNAC sends CoA to move it to VLAN 999 (quarantine).
• Privilege escalation: A user upgrades from guest to registered; CoA moves them from VLAN 50 to VLAN 100.
• Revocation: Admin marks an account as compromised; FAC sends a Disconnect-Request to bounce the session immediately.

Enabling CoA on FortiGate (FortiSwitch)

config switch-controller global
  set mac-aging-interval 300
  set allow-client-disconnect enable   # Required for CoA to work
end

The CoA packet arrives at FortiGate on UDP 3799 (from FAC or FortiNAC). FortiGate relays the CoA to the relevant FortiSwitch port.

CoA source IP

The CoA packet must come from an IP address that FortiSwitch/FortiGate trusts. Configure the allowed CoA source (FAC or FortiNAC IP) under the RADIUS server object or switch security policy.

---

Diagnostics

# Show 802.1X authentication state per port
diagnose switch-controller switch-info 802-1X S524DF4K15000024

# Show authenticated MAC addresses on a switch
diagnose switch-controller switch-info mac-filter S524DF4K15000024

# Show all MAC addresses on a switch (including dynamically learned)
diagnose switch-controller switch-info mac-table S524DF4K15000024

# Debug RADIUS exchange
diagnose debug application radiusd 255
diagnose debug enable
# Trigger auth attempt, then:
diagnose debug disable
diagnose debug reset

# On FortiAuthenticator — live auth debug
diagnose debug application authd 255
diagnose debug enable

---

Common Exam Scenarios

Q: 802.1X is enabled but all devices are landing in the guest VLAN regardless of credentials. A: Check the RADIUS server IP and shared secret on both FortiGate and FAC — an Access-Reject causes auth-fail VLAN, but no RADIUS response at all causes guest VLAN (timeout). If all devices go to guest VLAN, FortiSwitch cannot reach FAC. Verify firewall rules for UDP 1812 from the FortiGate IP to FAC.

Q: Dynamic VLAN assignment works for some users but not others. The users it fails for land in the static native VLAN. A: The RADIUS Access-Accept for those users is missing one of the three required VLAN attributes. Check the FortiAuthenticator attribute assignment for that user group — most commonly Tunnel-Medium-Type is missing.

Q: A printer is connected to an 802.1X-enabled port. After a few minutes it lands in the auth-fail VLAN instead of the printer VLAN. A: MAB is either not enabled in the security policy, or the printer’s MAC is not in the FAC MAC filter list. Add the MAC to FAC under Authentication > MAC Address Filter with the appropriate group and VLAN attributes.

Q: FortiNAC sends a CoA to quarantine a device but the port VLAN does not change. A: Check allow-client-disconnect enable on FortiGate switch-controller global settings. Also verify that the CoA packet arrives from an IP the FortiSwitch trusts (the CoA source IP must match what’s configured in the RADIUS client definition).