Troubleshooting NAT Port Forwards

If problems are encountered while attempting a port forward using pfSense® software, try the following.

Port Forward Testing Procedures

Follow the Guide

If the Port Forwards guide was not followed exactly, delete anything that has been tried and start from scratch with those instructions.

NAT Reflection

Port forwards do not work internally unless NAT reflection has been enabled. Always test port forwards from outside the network, such as from a client in another location, or from a 3G/4G device.

Setup Logging

Edit the firewall rule that passes traffic for the NAT entry and enable logging. Save and 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, etc, see below.)

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 it shows up. 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.

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

Check for Common Problems

Aside from the testing procedures outlined above, this section contains common problems with port forwards and how to resolve them.

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

Another thing to consider is that pfSense software may be forwarding the port properly, but a firewall on the target machine may be blocking the traffic. If there is a firewall on the target system, check its logs and settings to confirm whether or not 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 port forward traffic out whatever router the target has for its gateway, and then one of two things will happen: It will be dropped at that point 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 would 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 ports are being filtered by the ISP, 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 will only work when connections are made from outside of the local network. This is a frequent mistake when testing port forwards.

If port forwards are not required to work internally, see NAT Reflection. However, Split DNS (Split DNS) is a more proper and elegant solution to this problem without needing to rely on NAT reflection or port forwards, and it would be worth the time 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 must be used (VIPs, see Virtual IP Addresses). If a port forward on an alternate IP address is not working, a different type of VIP may be required. 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 or DMZ/1:1 NAT 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, or the firewall rules for the port forward would not reply back 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 the WAN interface tab under Firewall Rules will have 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(s) allowing the traffic in do 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, on the Firewall/NAT tab.

Gateways on Firewall Rules

WAN rules should NOT have a gateway set, so make sure that the rules passing traffic for the port forward do NOT have a gateway configured.

Check UPnP

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