pfSense Outbound NAT: Read the Generated Rules First

Open Firewall, then NAT, then Outbound, and read the mode before adding anything. In Automatic mode pfSense generates rules for the WAN interfaces and, among them, for remote-access VPN networks, so the pool you are about to add is often already covered. A missing hand-written row is not evidence that translation is missing. The order below keeps you from switching the whole firewall to Manual to solve one pool.

The mode decides who maintains translation for every other network on the box, which is a larger decision than one VPN exception.

Automatic Mode Already Covers the VPN Pool

Each mode has a distinct owner. Automatic generates rules for the WAN interfaces and includes remote-access VPN networks among its sources. Hybrid keeps those generated rules and lets you add manual ones beside them. Manual stops generating anything, so every translation on the firewall becomes your responsibility, including ones you did not write. A fourth setting disables outbound NAT entirely. A row that looks hand-written proves nothing until you know which mode is active.

In Automatic and Hybrid the page displays the generated rules as well. Read them before concluding that a VPN pool has no translation: look for the pool's network in the source column and the WAN interface in the interface column.

Choose Hybrid Only for a Reviewed Exception

A documented exception is still possible when the egress policy genuinely differs. Picture a server handing out 10.90.0.0/24, where the firewall should provide IPv4 internet egress and routing already selects WAN. The expected transformation is source 10.90.0.23 rewritten to the WAN address. Check whether a generated rule already does that on that exit; if not, Hybrid preserves automatic coverage while adding your reviewed rule.

Use the actual VPN pool as the source, or a supported alias for it, and never select an unrelated address because the OpenVPN instance name is missing from a picker. Avoid a source of any, which also translates traffic the firewall itself originates.

Do not move the whole firewall to Manual for one pool. That decision reassigns maintenance for every internal network and every future WAN change.

NAT Does Not Choose the Exit

Routing selects the egress interface; an outbound NAT rule only describes how the source gets rewritten once a packet leaves. A mapping for WAN does not force a packet that routing sent elsewhere onto WAN, which is why adding NAT cannot repair a wrong route. Inspect applicable 1:1 NAT entries and exceptions too, since order matters and a new row does not necessarily win. And the outbound page is not the filter page.

A translated source is not permission to reach every destination. Clients still need a route through the tunnel and a firewall rule that admits their traffic, and the chosen egress needs a working return path. Keep LAN-only access separate from internet-egress permission.

Prove the Transformation on a New Connection

After an approved change, test with a fresh authorized connection rather than reusing an existing one, because established states keep their earlier translation. Confirm the source address that actually leaves WAN and that the reply returns through the same state. Do not flush the whole state table as a first move; that hides which rule changed the outcome. Record the mode, the rule, the pool and the exit in the change ticket.

This example covers IPv4 egress only. It says nothing about an IPv6 translation or filtering policy, and a design that needs one has to state it separately. The finished record lists the permitted client traffic, the interface that carries it, and the reason its source needs rewriting at all.