Port Forwards¶

Port forwards allow access to a specific port, port range or protocol on a privately addressed internal network device. The name “port forward” was chosen because it is what most people understand in this context, and it was renamed from the more technically appropriate “Inbound NAT” to be more user-friendly. Similar functionality is also called “Destination NAT” in other products. However, “Port Forward” a misnomer, as port forward rules can redirect entire protocols such as GRE or ESP in addition to TCP and UDP ports, and it can be used for various types of traffic redirection as well as traditional port forwards. This is most commonly used when hosting servers, or using applications that require inbound connections from the Internet.

Risks of Port Forwarding¶

In a default configuration, pfSense® software does not allow any traffic initiated from hosts on the Internet. This provides protection from anyone scanning the Internet looking for systems to attack. When a port forward rule exists, the firewall will allow any traffic matching corresponding firewall rules. The firewall does not know the difference between a packet with a malicious payload and one that is benign. If the connection matches the firewall rule, it is allowed. Host based controls must be used by the target system to secure any services allowed through the firewall.

Port Forwarding and Local Services¶

Port forwards take precedence over services running locally on the firewall, such as the web interface, and SSH. For example this means if remote web interface access is allowed from the WAN using HTTPS on TCP port 443, a port forward on WAN for TCP 443 will take precedence and the web interface will no longer be accessible from WAN. This does not affect access on other interfaces, only the interface containing the port forward.

Port Forwarding and 1:1 NAT¶

Port forwards also take precedence over 1:1 NAT. If a port forward is defined on one external IP address forwarding a port to a host, and a 1:1 NAT entry is also defined on the same external IP address forwarding everything into a different host, then the port forward remains active and continues forwarding to the original host.

Port Forward Settings¶

When creating or editing a port forward entry, the following settings are available:

Disable:

A checkbox to optionally Disable this NAT port forward. To deactivate the rule, check this box.

No RDR (NOT):

Negates the meaning of this port forward, indicating that no redirection should be performed if this rule is matched. Most configurations will not use this field. This would be used to override a forwarding action, which may be needed in some cases to allow access to a service on the firewall on an IP address being used for 1:1 NAT, or another similar advanced scenario.

Interface:

The interface where the port forward will be active. In most cases this will be WAN. For additional WAN links or local redirects this may be different interface. The Interface is the location on the firewall where traffic for this port forward enters.

Address Family:

The address family for the IP address on which this port will be forwarded, either IPv4 or IPv6.

When an interface contains addresses of both families, the appropriate address will be used. Additionally, when selecting an interface it must have address which matches this type. When selecting a specific IP address, the address family must match the selected address.

Protocol:

The Protocol of the incoming traffic to match. This must be set to match the type of service being forwarded, whether it is TCP, UDP, or another available choice.

Most common services are TCP or UDP, but consult the documentation for the service or even a quick web search to confirm the answer. The TCP/UDP option forwards both TCP and UDP together in a single rule.

Source:

These options are hidden behind an Advanced button by default, and set to any source. The Source options restrict which source IP addresses and ports can access this port forward entry. These are not typically necessary.

If the port forward must be reachable from any location on the Internet, the source must be any. For restricted access services, use an alias here so only a limited set of IP addresses may access the port forward.

Unless the service absolutely requires a specific source port, the Source Port Range must be left as any since nearly all clients will use randomized source ports.

Destination:

The IP address where the traffic to be forwarded is initially destined. For port forwards on WAN, in most cases this is WAN Address. Where multiple public IP addresses are available, it may be a Virtual IP (see Virtual IP Addresses) on WAN.

If Invert Match is checked, the port forward will match any packet which does not match the specified destination instead.

Destination port range:

The original destination port of the traffic, as it is coming in from the Internet, before it is redirected to the specified target host.

Note

If forwarding a single port, enter it in the From port box and leave the To port box blank.

A list of common services is available to choose from in the drop down boxes in this group. Port aliases may also be used here to forward a set of services. If an alias is used here, the same alias must be used as the Redirect target port.

Redirect target IP:

The IP address where traffic will be forwarded, or technically redirected. When using an IPv6 target, it must be of the same scope as the destination.

Note

When using an alias as a value for this field, it should only contain a single IP address. Using multiple addresses will result in traffic being redirected to the target hosts in a round-robin fashion, but it is not ideally suited to that task. If one of the target hosts is down, traffic will still be forwarded to the unreachable target.

For situations requiring forwarding to multiple hosts, such as load balancing or failover scenarios, use the HAProxy package.

Redirect target port:

Where the forwarded port range will begin. If a range of ports is forwarded, e.g. 19000-19100, only the local starting point is specified since the number of ports must match up one-to-one.

This field allows opening a different port on the outside than the host on the inside is listening on. For example external port 8888 may forward to local port 80 for HTTP on an internal server. A list of common services is available to pick from in the drop down box.

Port aliases may also be used here to forward a set of services. If an alias is used here, the same alias must be used as the Destination port range.

Description:

As in other parts of pfSense, this field is available for a short sentence about what the port forward does or why it exists.

No XML-RPC Sync:

This option is only relevant if an HA Cluster configuration is in use, and should be skipped otherwise. When using an HA cluster with configuration synchronization, checking this box will prevent the rule from being synchronized to the other members of a cluster (see High Availability). Typically all rules should synchronize, however. This option is only effective on master nodes, it does not prevent a rule from being overwritten on slave nodes.

NAT Reflection:

This topic is covered in more detail later in this chapter (NAT Reflection). This option allows reflection to be enabled or disabled a per-rule basis to override the global default. The options in this field are explained in more detail in NAT Reflection.

Filter Rule Association:

This final option is very important. A port forward entry only defines which traffic will be redirected, a firewall rule is required to pass any traffic through that redirection. By default, Add associated filter rule is selected. The available choices are:

None:

If this is chosen, no firewall rule will be created.

Add associated filter rule:

This option creates a firewall rule that is linked to this NAT port forward rule. Changes made to the NAT rule are updated in the firewall rule automatically. If this option is chosen, after the rule is saved a link is placed here which leads to the associated firewall rule.

This is the default behavior and the best choice for most use cases.

Add unassociated filter rule:

This option creates a firewall rule that separate from this NAT port forward. Changes made to the NAT rule must be manually changed in the firewall rule. This can be useful if other options or restrictions must be set on the firewall rule rather than the NAT rule.

Pass:

This choice uses a special pf keyword on the NAT port forward rule that causes traffic to be passed through without the need of a firewall rule. Because no separate firewall rule exists, any traffic matching this rule is forwarded in to the target system.

Note

Rules using Pass will only work on the interface containing the default gateway for the firewall, they do not work with Multi-WAN.

Adding Port Forwards¶

Port Forwards are managed at Firewall > NAT, on the Port Forward tab. The rules on this screen are managed in the same manner as firewall rules (see Introduction to the Firewall Rules screen).

To add a port forward entry:

Navigate to Firewall > NAT, Port Forward tab
Click Add button to reach the Port Forward editing screen
Enter the options for the port forward as described in Port Forward Settings
Click Save
Click Apply Changes

Figure Port Forward Example contains an example of the port forward editing screen filled in with the proper settings to forward HTTP (port 80) inbound on WAN destined to the WAN IP address to the internal system at 10.3.0.15.

../_images/nat-portforward_example.png — Port Forward Example¶

After clicking Save, the port forward list is displayed again, and the newly created entry will be present in the list, as in Figure Port Forward List.

../_images/nat-portforward_inlist.png — Port Forward List¶

Double check the firewall rule, as seen under Firewall > Rules on the tab for the interface upon which the port forward was created. The rule will show that traffic is allowed into the internal IP address on the proper port, as shown in Figure Port Forward Firewall Rule.

../_images/nat-portforward_fwrule.png — Port Forward Firewall Rule¶

The Source of the automatically generated rule should be restricted where possible. For things such as mail and web servers that typically need to be widely accessible, this isn’t practical, but for remote management services such as SSH, RDP and others, there are likely only a small number of hosts that should be able to connect using those protocols into a server from across the Internet. A much more secure practice is to create an alias of authorized hosts, and then change the source from any to the alias. Otherwise, the server is wide open to the entire Internet. Test the port forward first with the unrestricted source, and after verifying it works, restrict the source as desired.

If everything looks right, the port forward will work when tested from outside the network. If something went wrong, see Troubleshooting NAT Port Forwards later in this chapter.

Tracking Changes to Port Forwards¶

As mentioned in Figure Firewall Rule Time Stamps for firewall rules, a timestamp is added to a port forward entry when it is created or last edited, to show which user created the rule, and the last person to edit the rule. Firewall rules automatically created by associated NAT rules are also marked as such on the associated firewall rule’s creation timestamp.

Port Forward Limitations¶

A single port can only be forwarded to one internal host for each available public IP address. For instance, if only one public IP address is available, one internal web server that uses TCP port 80 to serve web traffic can be configured. Any additional servers must use alternate ports such as 8080. If five available public IP addresses are configured as Virtual IP addresses, then five internal web servers using port 80 can be configured. See Virtual IP Addresses for more about Virtual IP addresses.

Tip

For services such as HTTP and HTTPS, port sharing may be possible by using the HAProxy package. If the requests can be distinguished in some way, such as by different request hostnames, a proxy can make more advanced decisions about how to forward requests to internal hosts.

There is one uncommon but sometimes applicable exception to this rule. If a particular port must be forwarded to a specific internal host only for certain source IP addresses, and that same port can be forwarded to a different host for other source IP addresses, that is possible by specifying the source address in the port forward entries, such as in Figure Port Forward Example with Different Sources.

../_images/nat-portforward_example_diffsources.png — Port Forward Example with Different Sources¶

In order for port forwards on WAN addresses to be accessible by using their respective WAN IP address from internal-facing interfaces, NAT reflection must be enabled, which is described in NAT Reflection. Always test port forwards from a system on a different Internet connection, and not from inside the network. Testing from a mobile device on 3G/4G is a quick and easy way to confirm external connectivity.

Service Self-Configuration With UPnP IGD & PCP¶

Some programs support Universal Plug-and-Play (UPnP IGD) or Port Control Protocol (PCP) to automatically configure NAT port forwards and firewall rules. Even more security concerns apply there, but in home use the benefits often outweigh any potential concerns. See UPnP IGD & PCP for more information on configuring and using UPnP IGD & PCP.

Traffic Redirection with Port Forwards¶

Another use of port forwards is for transparently redirecting traffic from an internal network. Port forwards specifying the LAN interface or another internal interface will redirect traffic matching the forward to the specified destination. This is most commonly used for redirecting all outbound DNS to one server.