Troubleshooting NAT Port Forwards

This document covers potential problems users may encounter with port forwarding on pfSense® software.

Port Forward Testing Procedures

Follow the Guide

If the Port Forwarding guide was not followed exactly, remove the problematic port forward entries and start from scratch by closely following the instructions in the guide.

NAT Reflection

Port forwards on external interfaces do not work from local clients without NAT reflection.

Always test port forwards from outside the network, such as from a client in another location, using a VPN to another region, or from a cellular device.

Setup Logging

Edit the firewall rule that passes traffic for the NAT entry and enable logging. Save and click Apply Changes. Then, try to access it again from the outside. Check the firewall logs (Status > System Logs, Firewall tab) to see if the traffic shows as being permitted or denied.

Check States

Check the states table under Diagnostics > States, filter on the source, destination, or port number to see if any entries are present. If entries are present that appear to match the NAT performed by the port forward, then the firewall is accepting and translating the traffic properly, so look at internal issues (e.g. client firewalls).

Check Packet Capture

Use a Packet Capture or tcpdump to see what is happening on the wire.

See also

Packet Capturing

This is the best means of finding the problem, but requires the most networking expertise. Navigate to Diagnostics > Packet Capture to capture traffic, or use tcpdump from the shell.

Start with the WAN interface, and use a filter for the appropriate protocol and port. Attempt to access from outside the network and see if the connection attempt shows in the packet capture. If not, the ISP may be blocking the traffic, or if Virtual IPs are involved they may have an incorrect configuration.

If the traffic is seen on the WAN interface, switch to the inside interface and perform a similar capture. If the traffic is not leaving the inside interface, there is a NAT or firewall rule configuration problem.

If packets leave the internal interface, but no traffic is coming back from the destination host, the target host default gateway may be missing or incorrect, it may not be listening on that port, or it may have a local firewall (Windows Firewall, iptables) blocking the traffic.

With certain types of packets return traffic may indicate the host is not listening on that port. For TCP, this is a TCP RST. For UDP, it can be an ICMP Unreachable message.

Check for Common Problems

This section contains common problems with port forwards and potential resolutions.

Missing or incorrect firewall rule

After checking the port forward settings, double check that the firewall rule has the proper settings. An incorrect firewall rule would also be apparent by viewing the firewall logs (Viewing the Firewall Log).

Remember, the destination for the firewall rule is the internal IP address of the target system and not the address of the interface containing the port forward. See Rules for NAT for more details.

Firewall is enabled on the target machine

pfSense software may be forwarding the port properly, but a firewall on the target host may be blocking the traffic. If there is a firewall on the target host, check its logs and settings to confirm whether the traffic is being blocked at that point.

Incorrect Gateway on Target

For pfSense software to properly forward a port for a local system, pfSense software must be the default gateway for the target host.

If pfSense software is not the gateway, the target host will attempt to send replies to forwarded requests out whatever router the target has for its gateway. At that point, one of two things will happen: It will be dropped there since there would be no matching connection state on that router, or it would have NAT applied by that router and then be dropped by the system originating the request since the reply is from a different IP address than the one to which the request was initially sent.

Target system has no gateway or cannot use pfSense software as its gateway

A subset of the larger problem of the target machine gateway is when the device has no gateway, or is incapable of having a gateway. In these cases, work around that problem by switching to Hybrid or Manual Outbound NAT and crafting a rule on the LAN or other internal interface facing the local device. This rule should translate traffic from any source going to the target host on the target port.

For example, if there is a file server that does not support a gateway located at 10.3.0.6, switch to Hybrid Outbound NAT and create a rule like Figure Manual Outbound NAT Rule for LAN Device with Missing Gateway to reach it from outside the network. The file server will see the LAN IP address of the firewall as the source of the traffic, and since that is “local” to the server, it will respond properly.

../_images/nat-outbound_example_localdevice.png

Manual Outbound NAT Rule for LAN Device with Missing Gateway

Target machine is not listening on the forwarded port

If the request is rejected instead of timing out when the connection is tested, in all likelihood pfSense software is forwarding the connection properly and the connection is rejected by the target host. This can happen when the target host has no service listening on the port in question, or if the port being forwarded does not match the port on which the target host is listening.

For example, if the target host is supposed to listen for SSH connections, but the port forward was entered for port 23 instead of 22, the server would most likely reject the request. The difference can typically be detected by trying to connect to the port in question using nc or telnet. A message such as “Connection refused” indicates something, frequently the inside host, is actively rejecting the connection.

See also

Using Diagnostics > Test Port can also help, see Testing a TCP Port.

ISP is blocking the port

Some ISPs filter incoming traffic to well-known ports. Check the Terms of Service (ToS) from the ISP to see if there is a clause about running servers. Such restrictions are more common on residential connections than commercial connections. When in doubt, a call to the ISP may clear up the matter.

If the ISP is filtering ports, moving the services to a different port may work around the restriction. For example, if the ISP disallows servers on port 80, try 8080 or 18080.

Before attempting to work around a filter, consult the ISP ToS to ensure that running a server is not a violation of their rules.

Testing from inside the network instead of outside

By default, port forwards only work when connections are made from outside the local network. This is a frequent mistake when testing port forwards.

If port forwards must work internally, see NAT Reflection. However, Split DNS (Split DNS) is the best practice solution to this problem. Split DNS does not rely on NAT reflection or port forwards, and it is worth the effort to implement that instead.

Even with NAT reflection, testing from inside the network isn’t necessarily indicative of whether it will work from the Internet. ISP restrictions, restrictions on devices upstream from the firewall, amongst other possibilities, are not possible to see when testing from within the network.

Incorrect or missing Virtual IP address

When using IP addresses that are not the actual IP addresses assigned to an interface, a Virtual IP address is necessary (VIPs, see Virtual IP Addresses). If a port forward on an alternate IP address is not working, it may require a different type of VIP. For example, a Proxy ARP type may be necessary instead of an “Other” type VIP.

When testing, also make sure that the client is connecting to the proper VIP.

pfSense software is not the border/edge router

In some scenarios pfSense software is acting as an internal router and there are other routers between it and the Internet also performing NAT. In such a case, a port forward must also be entered on the edge router forwarding the port to pfSense software, which will then use another port forward to get it to the local target host.

Note

Some upstream gear may also be able to change to a bridge mode to eliminate double NAT, or use a half bridge, 1:1 NAT, or DMZ mode to forward all traffic to the firewall running pfSense software.

Forwarding ports to a host behind Captive Portal

Forwarding ports to a host behind a captive portal needs special consideration. See Port Forwards Behind Portal Only Work When Target Logs In for details.

Return Routing

There are a few possible issues with return routing on WANs, particularly with multiple WANs.

  • If the port forward is on a WAN that is not the default gateway, make sure there is a gateway chosen on the corresponding WAN interface. Otherwise, the firewall rules for the port forward will not send reply packets via the correct gateway.

    The firewall will not add reply-to on the rules unless the interface is configured with a gateway.

  • If this is on a WAN that is not the default gateway, ensure the traffic for the port forward is NOT passed in via Floating Rules or an Interface Group.

    Only rules present on interface tab under Firewall Rules get the reply-to keyword to ensure the traffic responds properly via the expected gateway.

  • If this is on a WAN that is not the default gateway, make sure the firewall rule allowing the inbound traffic does not have the box checked to disable reply-to.

  • If this is on a WAN that is not the default gateway, make sure the master reply-to disable switch is not checked under System > Advanced, Firewall/NAT tab.

Gateways on Firewall Rules

WAN rules should NOT have a gateway set. Make sure that the rules passing traffic for port forwards do not have a gateway configured.

Check UPnP IGD & PCP

If the traffic appears to be forwarding in to an unexpected host, it may be happening due to UPnP IGD & PCP. Check Status > UPnP IGD & PCP to see if an internal host has configured a port forward unexpectedly. If so, disable UPnP IGD & PCP on either that host or on the firewall.