If you have created a 1:1 NAT or Port Forwarding entry and it does not have the expected effect, then there are several possible causes:

• You may have misconfigured the NAT entry
• The NAT entry may be configured correctly, but something else necessary for NAT to work was misconfigured (such as a firewall rule or a virtual IP address)
• There may be a software misconfiguration (such as port forwarding for a web server may be configured correctly, but the web server itself may be misconfigured)
• The issue may be beyond your control (such as, your ISP blocking a port)

As an initial step, you may want to try to access the resource locally (keeping in mind that if we are remapping the port from one port number to another, use the port number of the port on the local node hosting the resource). Use the local IP address of the node, even if you have NAT reflection enabled. If you can access the resource on the local network, but not on the WAN side, then at least you know the software is configured correctly. If not, you need to check to ensure the software or service is running and that it is configured correctly.

If the software is running and is accessible on the local network, you should make sure that the NAT entry is configured correctly. Check the IP addresses and port settings, as they have to be correct for NAT to work. In the case of port forwarding, make sure that Filter rule association is either set to Pass, or that there is an associated firewall rule for the NAT entry. You will also want to check the associated firewall rule to make sure that it allows the NAT traffic to pass. For example, make sure that the protocol for the NAT entry and the firewall rule match.

When checking the firewall rule, keep in mind that the entry for the rule in the rules table will tell you how much traffic has passed that matches the rule. If no traffic has passed (that is 0 states and 0 bytes), this is a good sign that the either the NAT rule is misconfigured or the traffic is not matching the firewall rule (a rule misconfiguration). This is one of the reasons why when adding a Port Forwarding entry, it is generally a better option to use Filter rule association to create a firewall rule rather than use the Pass option.

Also, keep in mind that for inbound NAT, typically we only need to configure the destination IP address and port. The source could be virtually anywhere, so we can usually leave this set to Any. Make sure that these options are configured correctly.

If you have checked the functioning of the underlying software of service and cannot find anything wrong with the NAT and firewall rule configuration, you might also consider the possibility that the port is blocked by your ISP. If it is a Port Forwarding entry, try changing the Destination port range setting and see if it works. You may also want to contact your ISP to see if any ports are blocked.  

Also consider that Port Forwarding only works on protocols that use ports (primarily TCP and UDP). With Port Forwarding, different hosts have the same WAN IP address, but different ports. Because only one connection can be handled at a time, the protocol must support the use of ports. For protocols that do not use ports, consider using 1:1 NAT or NAT traversal (creating a TCP or UDP tunnel through which the traffic will move).

Port Forwarding may also run out of ports if there are too many simultaneous connections (for example, we configure DCC to use ports 5198 to 5200, we can only have three simultaneous DCC connections). To prevent this from happening, you can either increase the range of ports, or create NAT entries with different target IPs (making sure the port ranges for the different IPs do not overlap).

Make sure that the Redirect target IP used in a Port Forwarding entry does not conflict with another IP address in the local network. IP address conflicts are just as harmful in Port Forwarding entries as they are elsewhere.

If you are trying to configure Outbound NAT, then keep in mind that Outbound NAT should be set to Automatic Outbound NAT unless there is a specific need to configure outbound NAT rules manually. If Outbound NAT is set to Manual Outbound NAT or Hybrid Outbound NAT, then make sure that source of traffic is matched. If the NAT settings are incorrect and your network uses private IP addresses, then traffic will not reach the WAN.

If you are configuring Outbound NAT for VPN usage, then make sure the following hold true:

• Make sure the rule for VPN traffic (such as, the ISAKMP rule for IPsec traffic is above the general pass-through rule for the interface (NAT entries, like firewall rules, are evaluated on a top-down basis).
• Make sure there is a rule for each interface on which VPN traffic will pass.

If you are configuring pfSense to act as a VPN client, you will also want to check with your VPN provider to find out what NAT entries must be created.

One possible problem with NAT is that incoming traffic may be reaching the target node, but the host may have a different default gateway. The outbound traffic will thus go out on a different router than the pfSense router from which the incoming NAT traffic came. As a result, the gateway for outgoing traffic may drop the connection, since there is no corresponding state in the state table, or it might send the outgoing traffic to the system originating the request, but the system will ignore the reply traffic because it has a different IP address than the WAN address of the pfSense router to which the request was sent. Therefore, you need to make sure that the incoming and outgoing gateway are the same.

It may be the case that pfSense is configured correctly, but the target node is running a firewall which blocks the request. If the system is running a firewall and you suspect the firewall may be blocking the connection, check the logs for the firewall and check the firewall settings.