FortiGate NSE4: NAT Rule Order When Addresses Overlap
FortiGate processes NAT rules in a strict top-to-bottom order, and when address objects or ranges overlap, the first matching rule wins. Understanding this behavior is critical for NSE4 certification and for avoiding unexpected traffic flows in production networks. This guide clarifies how FortiGate evaluates overlapping addresses and what happens when multiple NAT rules could apply to the same traffic.
How FortiGate Evaluates NAT Rules
FortiGate maintains a sequential NAT policy table. When a packet arrives, the firewall compares it against each NAT rule from top to bottom. The first rule whose source address, destination address, and service criteria all match the packet is applied immediately. No further rules are evaluated for that packet.
This first-match-wins behavior means that rule order directly determines which NAT translation occurs. If you have two rules that could both match a given packet, only the upper rule takes effect. The lower rule is ignored for that traffic, even if it is also technically valid.
Overlapping Address Scenarios
Overlapping addresses occur when two address objects or ranges share common IP space. Common scenarios include:
- →A host address (e.g., 10.0.1.5) and a subnet (e.g., 10.0.1.0 divided by 24) that contains it
- →Two subnets where one is a superset of the other (e.g., 10.0.0.0 divided by 16 and 10.0.1.0 divided by 24)
- →Multiple NAT rules translating different portions of the same source range to different destinations
- →Address groups that include overlapping member objects
When overlaps exist, FortiGate does not merge or deduplicate rules. Instead, it applies the first matching rule and stops. This means a packet matching both rule A and rule B will always use rule A if rule A appears higher in the policy list.
Practical Example: Order Matters
Consider this scenario:
Rule 1: Source 10.0.1.0/24 -> Translate to 203.0.113.0/25 Rule 2: Source 10.0.1.0/25 -> Translate to 203.0.113.128/25 Incoming packet from 10.0.1.50:
The packet source 10.0.1.50 matches both rules. However, FortiGate evaluates Rule 1 first. Since 10.0.1.50 falls within 10.0.1.0 divided by 24, Rule 1 matches and is applied. The packet is translated to 203.0.113.x. Rule 2 is never evaluated for this packet.
If you reverse the rule order, packets from 10.0.1.0 to 10.0.1.127 would match Rule 2 first and translate to 203.0.113.128 divided by 25, while packets from 10.0.1.128 to 10.0.1.255 would fall through and match Rule 1.
Best Practices for Overlapping Address NAT
- →Place more specific rules (smaller subnets, individual hosts) above more general rules (larger subnets) to ensure granular traffic receives intended treatment
- →Use address objects consistently; avoid creating duplicate or near-duplicate objects that might cause confusion
- →Document rule intent in the policy name or comments, especially when overlap is intentional
- →Test NAT rules with actual traffic or packet traces to verify the correct rule is matching
- →Review rule order after adding new NAT policies; insertion in the middle of a policy list can change behavior for existing traffic
- →Use the FortiGate GUI or CLI to display rule order explicitly; do not assume rules are ordered as you entered them
Verification and Troubleshooting
To verify which NAT rule is applied to a packet, use the diagnose command:
diagnose firewall iprule list diagnose nat traversal info diagnose debug flow filter addr <source> <dest> diagnose debug flow trace start 99
Packet traces show the exact rule ID and translation applied. This is invaluable when troubleshooting unexpected NAT behavior or confirming that overlapping rules are processed in the intended order.