# FortiGate Initial Configuration: Factory State, Access, and Operation Modes

> A FortiGate out of the box has a known factory state, and the first decisions made against it are hard to change later: NAT versus transparent operation mode, whether VDOMs are enabled, and how administrative access is reached. This covers the factory defaults, the difference between the two operation modes, what enabling VDOMs actually does, and the administrative-access settings that most often lock someone out.

Source: https://ronutz.com/en/learn/fortigate-initial-configuration-and-operation-modes  
Updated: 2026-07-25

---

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 DHCP 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.

**NAT 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 SD-WAN 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 SSH 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 VPN 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.