Outbound NAT configuration, as the name applies, covers traffic from our internal networks whose destination is an external network. The default NAT configuration in pfSense automatically translates outbound traffic to the WAN IP address. If there are multiple WAN interfaces, traffic leaving any WAN interface is automatically translated to the address of the WAN interface which is being used. If you navigate to Firewall | NAT and click on the Outbound NAT tab without having previously configured Outbound NAT, you will find that the default setting is Automatic outbound NAT rule generation.

The following screenshot demonstrates the default behavior of outbound NAT in pfSense on a relatively simple network with three interfaces: WAN, LAN (the 172.16.0.0 network), and DMZ (the 172.17.0.0 network). pfSense has generated two automatic rules. The first rule is an automatic rule for IPSec traffic. The second rule is the one that handles all other outbound NAT traffic. As you can see, outbound NAT takes all traffic that has as its source the loopback (127.0.0.0/8), the LAN and DMZ regardless of its destination and maps them to the WAN address. The sideways “X” in the static port column indicates that the outbound port is also translated to a random port. This makes sense, as it eliminates the possibility of a port conflict. For example, if a user requests a web page which uses the HTTPS protocol, and the outbound port was assigned the standard HTTPS port (443), then another user making a similar request would be unable to do so because the port is being used. By mapping the traffic to a random, unused port, pfSense avoids such problems:

If you want to confirm that NAT performs a necessary function on your network, select the Disable Outbound NAT radio button and then click on the blue Save button beneath the radio buttons. Unless you have configured your network so it is not dependent on NAT, you should find the internet is no longer accessible from nodes behind the pfSense box. Revert the setting back to Automatic outbound rule generation and the internet should be accessible again.

There are two other options for Outbound NAT Mode:

• Hybrid Outbound NAT rule generation will still automatically generate outbound NAT rules for each non-WAN interface, but you will also be able to create your own outbound NAT rules
• Manual Outbound NAT rule generation, if selected, will not automatically create any rules, although any previously created automatic rules will remain

It is good practice to document any changes we make to the settings, and this is especially the case if you select Manual Outbound NAT rule generation. If you select this, the previously created rules will remain, but if you add new interfaces, a NAT rule for the new interface will not be automatically created, which could cause bewilderment when you find the new subnet cannot access the internet. Nonetheless, this option could be useful if you want to filter certain traffic in order to make it easier to monitor.

To create or edit outbound NAT rules refer to, click on one of the Add buttons below the Mappings section. The first section of the page is Edit Advanced Outbound NAT Entry. The Disabled option just disables the rule, while Do not NAT completely disables NAT processing for traffic matching the rule. The Interface drop-down box allows you to select with Interface (as with almost every rule in which NAT is involved, this is usually set to WAN). Protocol allows you to specify the protocol the outbound rule applies to (usually we can keep it set to any, but you may want to create a more restrictive rule). Source is where you define where the traffic originates. This is almost always a subnet on your local network. For example, if we want to create an outbound rule for the DEVELOPERS network, and its subnet is 172.17.0.0/16, we would choose Network in the Type drop-down box, and enter 172.17.0.0 in the adjacent edit box and set the CIDR in the drop-down box to 16. Finally, Destination allows us to set a destination network for the outbound NAT mapping. Since we typically do not know the destination ahead of time, we usually set this to Any. The Not checkbox, if checked, inverts the sense of the destination match.

The Translation section of the page allows us to translate the IP address from the original internal address to another IP address. The default setting in the Address drop-down box is Interface Address, which just uses the IP address of the interface selected in the Interface drop-down box. We can also select Other Subnet, which will make additional options available. If we choose this option in the drop-down box, we can enter a different subnet in the Other subnet edit box; if we use this option, we need to define virtual IPs first, and use a subnet of virtual IPs.

The Pool options dropdown allows you to select how the subnet pool is used. The following options are available:

• Round Robin: This goes through the virtual IP addresses in a round-robin fashion; in other words, in a loop. It is the only option that works with host aliases.
• Random: This option will result in pfSense selecting an address from the virtual IP subnet randomly.
• Source Hash: This option will take the source IP address, hash it, and use the hash to determine the translation IP address. This guarantees that as long as the source IP address remains the same, the translation IP address will also remain the same.
• Bitmask: This option applies the subnet mask defined in Other subnet and keeps the last portion identical. Thus if we chose a virtual IP pool of 10.1.1.0/24 and the source IP is 192.168.1.12, the translated address will be 10.1.1.12.
• Round Robin with Sticky Address/Random with Sticky Address: These options invoke either Round Robin or Random addresses, but once an address is selected for a source IP address, it remains the same.

In the Port edit box, you can set the source port for the outbound NAT mapping. The Static port checkbox, if enabled, will prevent pfSense from rewriting the source port on outgoing packets. Rewriting the source port prevents other parties from finding out the original source port and thus thwarts fingerprinting nodes behind the firewall. Rewriting the source ports, however, breaks some applications, and in such cases, we can enable static ports for the rule.

The No XMLRPC Sync checkbox in the Misc section, if checked, will prevent the rule from syncing to other CARP members. You can also enter a brief description for future reference. When you are done, click on the Save button at the bottom of the page and the Apply Changes button on the main NAT page.