Outbound NAT modes — automatic, hybrid, and manual

OPNsense generates outbound NAT rules from a small set of templates, controlled by a single switch under Firewall → NAT → Outbound. The switch has three positions: Automatic outbound NAT (the default), Hybrid outbound NAT, and Manual outbound NAT. Each mode produces a different generated ruleset, and the difference matters in production estates where specific subnets need to egress specific WAN IPs.

This lesson covers the three modes, the rules they produce, and the operational decision points that lead an operator to move from the default to something more controlled.

The three modes in one paragraph

Automatic generates the rules for you. OPNsense creates one SNAT rule per active WAN interface: traffic from any source address egressing the WAN gets its source rewritten to the WAN’s IP address. The rule covers every internal subnet and every destination. This is the right default for single-WAN, single-LAN deployments — and the right place to start.

Hybrid generates the automatic rules and lets you add your own. The auto rules stay in place; you layer manual rules on top. PF evaluates rules top-to-bottom, and the first matching rule wins. Hybrid is the right mode when most outbound traffic should use the default WAN, but a specific subnet or destination needs different treatment.

Manual deletes the auto-generated rules entirely. OPNsense generates only the rules you define. Manual is required when the auto rules would conflict with your design — for example, when two WANs are present and you need explicit control over which source reaches which WAN, or when the auto rules would translate something that should not be translated.

$ pfctl -s nat | grep -v '^$'

nat on igb1 inet from 192.0.2.0/24 to any -> (igb1:0)
nat on igb1 inet from 10.10.0.0/24 to any -> (igb1:0)

The automatic mode in detail

When you select Automatic, OPNsense generates one nat rule per WAN interface, per internal subnet. The rule format is:

nat on <wan> inet from <internal-subnet> to any -> (<wan>:0)

The (igb1:0) syntax means “the primary IP address on the igb1 interface” — which is the WAN IP. PF translates any matching flow’s source to that address.

The auto rules cover every interface that has a configured IPv4 address and is not marked as a “WAN type” excluded from outbound NAT. By default, this means every internal interface on the firewall.

The generated rules are visible in the GUI under Firewall → NAT → Outbound as a read-only summary. You cannot edit them. You can see which interface they target and which subnet they cover.

The hybrid mode in detail

When you switch to Hybrid, OPNsense keeps the auto-generated rules and adds a section below them where you can create your own rules. The auto rules remain; your manual rules are evaluated in addition.

The placement of manual rules matters. PF evaluates NAT rules in order; the first match wins. If a manual rule is placed above an auto rule, the manual rule takes precedence for matching flows. If the manual rule is placed below, the auto rule matches first.

The convention in OPNsense: manual rules appear above auto rules in the GUI list, so a manual rule for a specific source subnet takes precedence over the auto rule that would otherwise catch it.

$ pfctl -s nat | head -10

nat on igb1 inet from 10.99.0.0/24 to any -> (igb2:0)
nat on igb1 inet from 192.0.2.0/24 to any -> (igb1:0)
nat on igb1 inet from 10.10.0.0/24 to any -> (igb1:0)

The manual mode in detail

When you switch to Manual, OPNsense deletes the auto-generated rules. The GUI then shows only the rules you create. There is no implicit default. If a flow has no matching nat rule, PF will not translate it, and outbound traffic from that source will fail because the remote server has no return path (or, more likely, the firewall’s default route is via a different interface than the flow’s source and the return fails).

Manual mode is required in three situations:

• Multi-WAN estates where auto rules collide. Two WANs, two internal subnets, and a strict requirement that subnet A egresses WAN-A and subnet B egresses WAN-B. Auto rules would catch every subnet and route it through the WAN chosen by the routing table — typically WAN-A. Manual rules let you express the binding.
• Specific outbound exceptions. A server subnet that should not be translated (because it has a public IP itself, or because it is reached via a VPN that requires the original source). Manual rules let you create a “do not translate” rule explicitly.
• Compliance constraints. Some regulatory environments require explicit NAT rules for audit purposes. Manual mode produces an audit-friendly ruleset.

When to choose which mode

The decision tree:

1. Single WAN, single internal subnet? Use Automatic.
2. Single WAN, but you need to exempt one subnet from NAT? Use Hybrid. Add a manual rule for the subnet that uses the WAN IP as both source and translation target, which is effectively a no-op translation — but you must use Manual if the subnet should not be translated at all, because in Hybrid the auto rule below would still match.
3. Multiple WANs with subnet-to-WAN binding? Use Manual. The auto rules in Hybrid or Automatic mode would route every subnet through one WAN (the one chosen by the routing table), which is not what you want.
4. Audit-driven environment? Use Manual. The ruleset is explicit and reviewable.

A migration sequence that does not break traffic

The production pattern for moving from Automatic to Manual:

1. Inventory the auto rules. Run pfctl -s nat and capture the output. Each line corresponds to one auto rule.
2. Switch to Hybrid. The auto rules remain. Verify with pfctl -s nat that the rules are unchanged.
3. Add manual rules. Create one manual rule per auto rule you want to recreate. Place each manual rule to match the auto rule’s behaviour exactly.
4. Test. Verify outbound traffic from each subnet still translates correctly. Use tcpdump -nei igb1 to see the post-NAT source on outbound traffic.
5. Switch to Manual. With the manual rules in place, the deletion of the auto rules should not change observable behaviour.
6. Verify. pfctl -s nat shows only your manual rules. Test outbound traffic from every subnet again.

A common mistake: editing auto rules in Hybrid

A frequent failure mode: an operator switches to Hybrid to add a manual rule, then sees the auto rules in the GUI list and tries to edit one of them. The GUI does not let you edit auto rules in Hybrid — they are read-only. To change an auto rule’s behaviour, you must switch to Manual and recreate the rule manually.

The misconception is that Hybrid is a “softer” mode that lets you tweak the auto rules. It is not. Hybrid keeps the auto rules exactly as generated; your only control is adding manual rules on top.

Summary

• Automatic outbound NAT generates one nat rule per WAN per internal subnet. Default mode, fine for single-WAN.
• Hybrid keeps the auto rules and lets you add manual rules on top. Right when most traffic should use the default but a subset needs different treatment.
• Manual deletes the auto rules; you define everything. Required for multi-WAN subnet pinning and audit-driven environments.
• Switching modes changes the running ruleset immediately. Plan the migration: capture auto rules, switch to Hybrid, recreate in Manual, verify.
• A flow with no matching nat rule in Manual mode silently fails. Cover every internal subnet with a manual rule.