Firewall placement, segmentation and zero trust

A real-life situation

Harbourline Foods, a fictional company, has one FortiGate at its head office. Staff browse the Internet, and customers reach a web shop in the DMZ. The company now moves its database off the web server onto a new server, DB1. Where should DB1 go? On the staff LAN it would be one compromised laptop away from every customer record. In the DMZ it would share a segment with the Internet-facing web server. The right answer is a new segment for servers, with the FortiGate between it and everything else, and a short list of allowed connections. That is firewall placement and segmentation, and this lesson ends with that exact design.

The examples use the course lab:

Why placement matters

A firewall decides only for traffic that passes through it. Two hosts in the same subnet talk to each other directly through the switch, so a firewall in another part of the network doesn't see that traffic. Placement therefore answers two questions: which boundaries need enforcement, and how traffic is forced through the firewall at each of them. In practice the answer is routing: the firewall is made the default gateway of each segment it protects, or sits in the only path between two parts of the network.

Learn more: Stateless, Stateful and Next-Generation Firewalls

North–south and east–west traffic

Older designs protected only north–south traffic and trusted everything inside. Modern attacks rarely stop at the first host: ransomware spreads from one laptop to file servers and backups over east–west paths. Controlling east–west traffic is what limits how far one compromise can spread.

Where firewalls are placed

These roles can be separate devices or one FortiGate doing several. In the course lab, FGT1 is both the edge firewall (port1 to the Internet) and an internal firewall (LAN to DMZ). That is normal in small and medium sites. Large networks usually separate the roles so each firewall can be sized and changed independently.

Deployment modes: NAT mode and transparent mode

Placement also decides how the FortiGate joins the network. FortiOS offers two operation modes, set per VDOM:

In NAT mode, "NAT" names the mode, not a requirement: each policy decides whether source NAT is applied. An ISFW policy between two internal segments normally has NAT off, so servers see the real client addresses. Transparent mode keeps the existing addressing, but the FortiGate is no longer a Layer 3 hop, so features that depend on routing, such as SD-WAN and dynamic routing, don't apply. A third option sits in between: a virtual wire pair joins two ports of a NAT-mode FortiGate as a bump in the wire, without changing the whole VDOM's mode.

Checking and changing the mode

FGT1 # get system settings | grep opmode
opmode              : nat

Switching a VDOM to transparent mode is done under config system settings, together with the management IP address and its default gateway (the FortiGate needs them to reach FortiGuard and to be managed, because the traffic interfaces no longer have addresses):

Zones and DMZ design

A DMZ (demilitarised zone) is a segment for servers that the Internet must reach, such as WEB1. It exists so that a compromised public server doesn't sit next to staff PCs. The rules that make a DMZ work:

• Internet → DMZ: only the published services (for WEB1, HTTPS through a virtual IP).
• DMZ → LAN: nothing by default. A web server rarely needs to open connections to staff PCs.
• LAN → DMZ: only what staff and administrators need, for example HTTPS and SSH from an admin group.
• DMZ → Internet: only what the servers need, such as operating system updates, not general browsing.

On a FortiGate, policies are written between interfaces. A zone groups several interfaces so one policy covers them all, which keeps the policy table short when segments get the same treatment. Traffic between interfaces of the same zone is controlled by the zone's intrazone setting:

An interface that is already referenced directly by a policy or route can't join a zone until those references are removed. Plan zones before writing policies, and keep intrazone deny where the members should be isolated from each other, such as two DMZ servers belonging to different customers.

Learn more: Interfaces, VLANs and Zones

Segmentation by VLAN and policy

A VLAN separates a switch into separate Layer 2 networks. On its own, that only splits broadcast domains; the security comes from what connects the VLANs. If FGT1 is the default gateway of every VLAN, all traffic between them crosses FGT1, and each pair of segments needs an explicit policy.

Micro-segmentation takes the idea further: policies per workload or per application rather than per subnet, so even two servers in the same segment can only talk on the ports they need. It is usually enforced close to the workload, by host firewalls, the hypervisor or the cloud platform, because a firewall between subnets doesn't see traffic inside one subnet. A FortiGate supports the idea at the subnet level with narrow address objects and per-application policies; true per-workload enforcement is beyond this course.

Zero trust principles

Zero trust (described in NIST SP 800-207) replaces "trusted inside, untrusted outside" with three ideas:

• Don't trust by location. Being on the office LAN or on the VPN grants nothing by itself.
• Verify identity and device. Each access decision checks who the user is and whether the device is known and healthy.
• Least privilege. Grant access to specific applications, not whole networks, and only for as long as it is needed.

How a FortiGate relates to these ideas, at a concept level:

A ZTNA access proxy differs from a traditional VPN: instead of placing a remote device onto the internal network, it gives the user access to one application at a time, after checking identity and device posture. Configuring ZTNA and identity-based policies is beyond Fortinet Fundamentals; this lesson only places them in the design.

Learn more: Users and Firewall Authentication

A worked design: adding a server segment

Back to Harbourline Foods. The new database server DB1 (10.0.30.20) goes into a SERVERS segment, VLAN 30, carried on port2 alongside the staff LAN. FGT1 becomes its gateway, so every connection to DB1 crosses a policy.

Then the policy table, written from the services each system actually needs:

Policy 1 is the ISFW rule that matters most: if WEB1 is compromised, the attacker can reach DB1 only on the database port, not with SSH or file sharing. Policy 2 uses identity rather than a whole subnet, the zero-trust habit applied to an internal policy. NAT is off on internal policies so DB1's logs show real client addresses. Here is policy 1 in the CLI, with address objects named WEB1 and DB1:

Verifying the design

Test both what should work and what shouldn't. From WEB1, connect to DB1 on TCP 5432 (it should work) and on TCP 22 (it should fail). Then confirm what FGT1 decided:

FGT1 # diagnose sys session list
session info: proto=6 proto_state=01 duration=12 expire=3593 timeout=3600 ...
...
hook=pre dir=org act=noop 10.0.2.10:40112->10.0.30.20:5432(0.0.0.0:0)
...
misc=0 policy_id=5 ...
total session 1

The GUI's Policy Lookup (Policy & Objects › Firewall Policy) answers "which policy would match this connection?" without generating traffic, which is useful before a change goes live.

What can go wrong

Servers in the new VLAN can't reach anything

DB1 has an address in 10.0.30.0/24 but can't even ping its gateway, 10.0.30.1.

Two hosts "in different segments" talk without a policy

The firewall logs show nothing, yet a guest device reaches a server.

An interface can't be added to a zone

The GUI or CLI rejects adding port3 to DMZ-ZONE.

The application breaks after segmentation

The web shop shows database errors after the server move, although policy 1 exists.

Design guidance for enterprises

• Separate roles as the network grows. An edge FortiGate for Internet, VPN and SD-WAN; an ISFW pair in the core or data centre sized for internal volumes.
• Size an ISFW for east–west volume. Internal traffic such as backups can far exceed Internet traffic; size by the inspection you will turn on.
• Plan segments by trust and function. Users, servers, management, guests, OT and IoT devices, and the DMZ each get their own segment.
• Deploy in HA. A firewall in the only path between segments is a single point of failure.
• Introduce zero trust in steps. Identity-based policies for sensitive servers first, then device posture, then per-application access for remote users.

Learn more: High Availability (FGCP)

Best practices

• Make the firewall the default gateway of every segment it must protect, and remove other routed paths.
• Start from deny between segments; add policies per service, with named address objects.
• Turn source NAT off on internal policies so logs keep real addresses.
• Put Internet-facing servers in a DMZ and give the DMZ no access to the LAN by default.
• Use zones only where segments really share the same policy; otherwise keep interfaces separate.
• Log internal policies, especially to servers; east–west logs are where lateral movement shows up.

Key takeaways

Check yourself

Next: The Fortinet product family and the Security Fabric. To build these policies on a FortiGate, see How firewall policies work.