The first hour with a new FortiGate sets three things that are awkward to reverse: which operation mode it runs in, whether it is split into VDOMs, and how you reach it. Each has a default, and each default is right for some deployments and wrong for others.
The factory state
A FortiGate ships with a known configuration. The internal interface holds a documented management address and runs a server, so a laptop plugged into it gets an address and can reach the web interface immediately. The admin account has no password. There are no firewall policies, which combined with the implicit deny means nothing passes until you write one: a new unit is not permissive by default, it is inert.
A factory reset returns to exactly that state, which matters during recovery: it is a known baseline rather than a partially cleaned configuration.
execute factoryreset
The first configuration step is always the same, and it is the one people postpone: set the admin password. A unit with the default blank password reachable from anywhere is the most common finding in any FortiGate audit.
NAT mode and transparent mode
The operation mode determines what the device is on the network.
mode is the default and the usual choice. Interfaces have IP addresses, the device routes between them, and it acts as a gateway. Everything about policies, NAT, routing and (software-defined ) assumes this mode.
Transparent mode turns the device into a bump in the wire. Interfaces have no IP addresses, the FortiGate bridges between them at layer 2, and hosts on either side are unaware it exists. It gets a single management IP for administration and nothing else. This is what you use to insert inspection into an existing segment without re-addressing anything, a common requirement when the network cannot be changed but the traffic must be inspected.
| NAT mode | Transparent mode | |
|---|---|---|
| Interface addressing | Each interface has an IP | No interface IPs; one management IP |
| Role | Router and gateway | Layer 2 bridge |
| Routing, NAT, SD-WAN | Available | Not applicable |
| Visible to hosts | Yes, as their gateway | No |
| Typical use | The network edge | Inserting inspection into an existing segment |
Switching modes erases most of the configuration, because the two modes do not share meaningful settings. That is why the choice belongs at the start rather than later.
VDOMs split one device into several
Virtual domains partition a FortiGate into independent units, each with its own interfaces, policies, routing table and administrators. Traffic does not pass between VDOMs unless you deliberately link them.
The reasons to enable them are real: separating tenants or business units that must not see each other's configuration, keeping test and production apart on one appliance, or delegating administration without granting global rights.
The cost is that every operation acquires a context. Configuration commands, diagnostics and routing all become per-VDOM, and a command run in the wrong VDOM returns a truthful answer about the wrong network. That single confusion accounts for a large share of "the configuration is correct but it does not work" reports on multi-VDOM devices.
There is always a management VDOM, which owns the device's own outbound traffic: updates, logging, and DNS for the system itself.
Administrative access, and how people lock themselves out
Each interface has a set of permitted administrative protocols. Enabling HTTPS and on an internal interface is ordinary; enabling them on the WAN interface exposes the management plane to the internet, and doing so without restriction is how appliances end up in mass-exploitation reports.
Two controls matter more than the protocol list:
Trusted hosts restrict an administrator account to specific source addresses. This is per-account, not per-interface, and it is the stronger control: even if management is reachable, only the listed sources can authenticate. It is also the classic self-inflicted lockout, because a trusted host entry that does not include your current address takes effect immediately.
Changing the management ports moves HTTPS and SSH off 443 and 22. This is not security by itself, and it does meaningfully reduce noise from indiscriminate scanning. It also frees 443 for a (virtual private network) or virtual server on the same interface, which is often the actual motivation.
The recovery path when access is lost is console access over the serial port, which no software setting can block. Any FortiGate deployment where the console is not reachable has no recovery path short of a site visit, and that is worth knowing before it matters.
What an exam candidate should be able to state cold
Factory state: known internal address, DHCP on internal, blank admin password, no policies and therefore no traffic. NAT mode routes and is the default; transparent mode bridges at layer 2 with a single management IP, and switching between them erases the configuration. VDOMs give independent policy and routing tables with a management VDOM for the device's own traffic, and every command becomes context-sensitive. Administrative access is controlled per interface by protocol and per account by trusted host, and the console is the recovery path.
This series, in order
This article opens the series FortiGate administration. The first decisions against a factory-fresh unit are the hardest to change later; the parts follow an administrator from there in the order the work comes: the , then policy and translation and why a rule did not fire, the two tools that show a packet's path, routing, inspection, identity, tunnels, redundancy and logging, and finally the features found at a deployment's edges.
- The FortiOS CLI verb that quietly deletes things. config, edit, set, next, end: a small grammar with three traps, one of which quietly deletes things.
- FortiGate Firewall Policies and NAT: Matching Order, SNAT, and DNAT. Policies evaluated top to bottom with the first match winning, and source and destination translation inside them.
- Why your FortiGate rule did not fire. Why a narrower rule below a broader one never fires, and the policy ID that is not the order.
- Reading a FortiGate debug flow. The diagnose debug flow sequence as a recipe: why its order matters, and why the cleanup matters more.
- Reading a FortiGate Packet Sniffer Trace. The five positional arguments of the packet sniffer, and how to read what it prints.
- FortiGate Routing and SD-WAN: Route Selection Order and Rule Evaluation. Policy routes before the routing table, the most specific route first, and how software-defined WAN rules choose a path.
- FortiGate Security Profiles: Antivirus, IPS, and Application Control. Antivirus, intrusion prevention system and application control profiles, and what each can see in flow or proxy mode.
- FortiGate SSL Inspection: Certificate vs Deep Inspection. Certificate inspection reads only the name and certificate; deep inspection decrypts, with everything that implies.
- FortiGate Firewall Authentication and FSSO: Identity in a Policy. A user instead of an address in a policy: active authentication, and single sign-on fed by the directory.
- FortiGate IPsec VPN: Phase 1, Phase 2, and Redundant Topologies. Virtual private network tunnels in two phases, knowing which one failed, and mesh, and redundant designs.
- FortiGate FGCP High Availability: Active-Passive, Active-Active, and Failover. Two or more units under FGCP: the override-sensitive election, session sync, and failover.
- FortiGate Logging and Diagnostics: Where Logs Go and How to Find a Problem. The log destinations and what each keeps, and why a policy that does not log leaves nothing to investigate.
- FortiGate Traffic Shaping and QoS: Guaranteeing Bandwidth That Is Already Full. Shaping only matters on a congested link: it decides who suffers when there is not enough.
- FortiGate as a DNS server: four modes, and where the filter applies. Relay, local database or full resolver: four DNS modes, how each fails, and where the DNS filter applies.
- Carrier-Scale NAT, MAP-E, Domain Fronting, and WCCP. -scale translation, MAP-E, domain fronting and : the features at the edges of a deployment.
- ACME on FortiGate: a built-in client for the box's own certificate. The built-in client that obtains and renews the FortiGate's own certificate, and its requirements.