Accessing FortiSwitch CLI Through FortiGate: A Technical Investigation

January 30, 2026.

Master FortiSwitch CLI access via FortiGate CLI with FortiLink configuration, authentication methods, and essential commands for network administrators.

When network engineers manage Fortinet's integrated security fabric, a recurring operational question emerges: how does one reach the command-line interface of a FortiSwitch unit when it operates under FortiGate control? The answer lies not in direct console cables or standalone SSH sessions, but in a carefully orchestrated pathway through the FortiGate's own CLI—a design choice that centralizes management while introducing specific procedural requirements. This investigation dissects the mechanisms, prerequisites, and command sequences that enable secure, efficient access to FortiSwitch CLI resources from a FortiGate management console.

Understanding the FortiLink Foundation

FortiLink serves as the control plane binding FortiGate and FortiSwitch units into a single administrative domain. Before CLI access becomes possible, this logical tunnel must be correctly instantiated and authorized.

Prerequisites and Network Requirements

Successful CLI traversal demands three foundational conditions. First, the FortiSwitch must be physically connected to a FortiLink-capable port on the FortiGate and recognized as a managed device. Second, the administrator requires privileged CLI access to the FortiGate itself. Third, Layer 2 connectivity must exist between the two devices, or—if operating over Layer 3—appropriate routing and discovery parameters must be configured. Without these elements, CLI access attempts will fail at the authentication or transport layer.

FortiLink Interface Configuration Methods

Administrators may establish FortiLink on either a physical port or a logical aggregate interface. For physical port configuration, the sequence begins by removing the target port from any existing virtual switch, then enabling FortiLink and auto-authorization:

config system interface     edit port1         set auto-auth-extension-device enable         set fortilink enable     next end 

Following interface preparation, the FortiSwitch unit must be explicitly authorized within the switch-controller configuration. This step triggers a controlled reboot of the switch to apply management policies:

config switch-controller managed-switch     edit FS224D3W14000370         set fsw-wan1-admin enable     next end 

When using link aggregation groups or hardware switches as the FortiLink carrier, additional parameters such as LACP mode and split-interface settings become relevant, particularly in multi-switch topologies.

CLI Access Pathways: Methods and Authentication

Once FortiLink is operational, two primary methods enable CLI access to the managed FortiSwitch: direct console proxying through the FortiGate, and SSH tunneling over the CAPWAP control channel.

Direct Console Access via FortiGate

The most straightforward approach leverages the FortiGate's ability to proxy terminal sessions. After confirming the FortiSwitch appears in the managed devices list, administrators initiate a CLI session using the execute switch-controller console command followed by the switch's serial number or assigned name. This method requires no additional network configuration beyond the established FortiLink tunnel and inherits the FortiGate's authentication context, simplifying access control.

SSH-Based Remote Access Over CAPWAP

For environments requiring scriptable or remote terminal access, SSH provides an alternative pathway—but with important constraints. When FortiSwitch management operates via CAPWAP (rather than HTTPS), the FortiGate dynamically registers a DNS entry for each authorized switch using the .fsw domain suffix. Administrators may then connect directly:

execute ssh admin@FS224D3W14000370.fsw 

This technique fails if the switch is managed via HTTPS, as no DNS record is created in that mode. In such cases, SSH access must target the switch's management IP address directly, bypassing the FortiGate proxy entirely.

Essential Commands and Operational Verification

Accessing the CLI represents only the first step; effective management requires familiarity with diagnostic and monitoring commands that operate within the FortiSwitch context.

Diagnostic and Monitoring Commands

Several commands prove indispensable for real-time operational insight. To observe port state transitions, filter the event log by link status:

exec log filter field status up, down exec log display 

For MAC address table verification across managed switches, the diagnostic command diag switch-controller dump mac-addr returns a comprehensive mapping. When investigating a specific device, append the switch identifier to narrow results. Spanning-tree events, critical for loop prevention, surface through subtype filtering:

exec log filter field subtype spanning_tree exec log display 

Logging and Troubleshooting Techniques

Centralized logging configuration allows FortiSwitch events to populate the FortiGate's event database. Administrators may override global logging defaults per switch:

config switch-controller managed-switch     edit <switch-id>         config switch-log             set local-override enable         next     next end 

Subsequent severity filtering—ranging from emergency to debug—enables precise control over which events propagate to the central console. This capability proves vital during incident response, where signal-to-noise ratio directly impacts resolution speed.

Layer-3 Management Considerations

Deployments where FortiSwitch units reside beyond the FortiGate's immediate broadcast domain require FortiLink over Layer 3. This architecture supports both in-band management (using the switch's internal data interface) and out-of-band management (via the dedicated mgmt port). Configuration demands explicit discovery settings—either DHCP option 138 or static controller IP specification—and careful sequencing of global and interface commands to ensure the switch correctly identifies its management endpoint. Notably, port splitting functionality remains unsupported in Layer 3 FortiLink mode, a constraint that influences high-availability design decisions.

Frequently Asked Questions

Q: Can I access FortiSwitch CLI if the switch is managed via HTTPS instead of CAPWAP?
A: Direct SSH access using the .fsw DNS suffix requires CAPWAP-based management. When HTTPS management is enabled, administrators must use the FortiGate's console proxy command or connect via the switch's dedicated management IP address.

Q: What happens when I authorize a FortiSwitch with set fsw-wan1-admin enable?
A: The FortiSwitch unit undergoes a controlled reboot to apply the management policy and establish the FortiLink control channel. This process typically completes within 60–90 seconds, after which CLI access becomes available.

Q: How do I verify which FortiSwitch units are currently managed by my FortiGate?
A: Execute diagnose switch-controller switch list on the FortiGate CLI. This command returns serial numbers, management status, and FortiLink interface associations for all discovered switches.

Q: Is it possible to run native FortiSwitchOS commands from the FortiGate CLI?
A: Yes. Once a console session is established to a managed FortiSwitch, all standard FortiSwitchOS CLI commands execute as if connected directly to the switch's console port.

Q: What troubleshooting steps should I take if CLI access fails after FortiLink configuration?
A: First, confirm the FortiSwitch appears as "Authorized" in the managed-switch list. Next, verify Layer 2 connectivity on the FortiLink port and check for IP address conflicts. Finally, review FortiGate system logs for CAPWAP negotiation errors or authentication failures.