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” after countless complaints from confused users. Similar functionality is also called “Destination NAT” in other products. However, “Port Forward” a misnomer, as port forward rules can redirect GRE and ESP protocols 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.
For additional information, you may access the Hangouts Archive to view the May 2016 hangout for NAT on pfSense 2.3, The June 2016 hangout on Connectivity Troubleshooting, and the December 2013 Hangout on Port Forward Troubleshooting, among others.
Risks of Port Forwarding¶
In a default configuration, pfSense does not let in 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, pfSense will allow any traffic matching the corresponding firewall rule. It 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 any services running locally on the firewall, such as the web interface, SSH, and so on. 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.
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 begin adding a port forward entry, click Add button to reach the Port Forward editing screen. The following options are available for port forwards:
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 being used for 1:1 NAT, or another similar advanced scenario.
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.
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 being forwarded will be 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.
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.
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.
- 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. 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. An alias here, but the alias must only contain a single address. If the alias contains multiple addresses, the port will be forwarded to each host alternately, which is not what most people want. To setup load balancing for one port to multiple internal servers, see Server Load Balancing.
- 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.
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:
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. This is the best choice for most use cases. If this option is chosen, after the rule is saved a link is placed here which leads to the associated firewall rule.
- 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.
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.
Rules using Pass will only work on the interface containing the default gateway for the firewall, so they do not work effectively with Multi-WAN.
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 inbound on WAN destined to the WAN IP address to the internal system at 10.3.0.15.
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.
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.
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 Port Forward Troubleshooting 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.
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.
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 or NAT-PMP¶
Some programs support Universal Plug-and-Play (UPnP) or NAT Port Mapping Protocol (NAT-PMP) 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 & NAT-PMP for more information on configuring and using UPnP and NAT-PMP.
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 transparently proxying HTTP traffic to a proxy server, or redirecting all outbound DNS to one server.
The NAT entries shown in Figure Example Redirect Port Forward are an example of a configuration that will redirect all HTTP traffic coming into the LAN interface to Squid (port 3128) on the host 10.3.0.10, but will not redirect the traffic coming from the actual squid proxy itself. They must be in the correct order in the list of port forwards: The negate rule first, then the redirect.