pfSense Port Forwarding Not Working? Fix It Step by Step

Typing “pfsense port forwarding not working fix” into a search engine returns a decade of forum threads that end in the same nine places, and almost none of them is a bug in pf. A port forward is two objects, a NAT redirect and a firewall pass rule, plus three things outside the firewall: the WAN address, the target host’s routing, and where you test from. Work the checks in order. The running example is WAN igc0 at 203.0.113.10, LAN 192.168.10.0/24 with pfSense at 192.168.10.1, and a service on 192.168.10.20 listening on TCP 8443, exposed on external TCP 443.

Check 1: you are testing from the wrong side

Netgate’s troubleshooting page states it flatly: “Port forwards on external interfaces do not work from local clients without NAT reflection.” A laptop on 192.168.10.0/24 hitting 203.0.113.10:443 is not a valid test. Use a phone on cellular data or a VPS:

nc -vz -w 3 203.0.113.10 443 || echo "no path to 203.0.113.10:443"

A fast “Connection refused” means something answered. A silent timeout means the packet died on the way; the rest of the list finds where. Inside testing is check 9.

Check 2: the WAN address is not public

Read the WAN IPv4 address in Status > Interfaces. If it sits inside 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16, the blocks RFC 1918 reserves for private internets, pfSense is behind the ISP’s own NAT. The docs say to “configure port forwards on edge routers pointing to pfSense first”: the ISP router must forward TCP 443 to pfSense’s WAN address. Bridge mode on the ISP device is cleaner.

If the WAN address sits inside 100.64.0.0/10, that is the Shared Address Space RFC 6598 allocated for Carrier-Grade NAT. No pfSense setting helps, because the ISP’s CGN never delivers the inbound connection. Ask for a public address, or use an overlay; WireGuard vs Tailscale for home networks covers the two routes out of CGNAT.

Related trap: the WAN option “Block private networks and loopback addresses” is a rule that “prevents any RFC 1918 networks … from communicating on that interface,” per the interface docs. It matches source addresses, so internet clients arriving through an upstream DNAT survive, but a test client on the ISP router’s 192.168.1.0/24 transit network is exactly what it drops.

Check 3: the pass rule is missing or aims at the wrong destination

A port forward is only a redirect; the Port Forwards reference warns: “Without a firewall rule to pass the packets, the firewall will drop them.” Check Firewall > Rules > WAN.

Its destination must be the internal target, 192.168.10.20 port 8443, not WAN address port 443. The redirect rewrites the destination before rules are evaluated, so a rule matching the public address never sees the packet. Leaving Filter rule association on “Add associated filter rule” creates and syncs the right rule.

Then check order. pfSense evaluates floating rules, then interface group rules, then interface rules, and “the rules are processed until a match is found.” A block in Floating, or a pfBlockerNG deny rule sorted above your pass rule, shadows it silently. Enable logging on the pass rule and read Status > System Logs > Firewall to see which rule won.

Check 4: the NAT entry itself

In Firewall > NAT > Port Forward verify four fields:

• Interface is WAN. A forward on LAN never matches inbound internet traffic.
• Protocol matches the service. HTTPS and SSH are TCP, WireGuard is UDP.
• Destination is WAN address, or a Virtual IP for an additional public address. The reflection troubleshooting page records what any does: “any connection made on the firewall comes up as the local web server.”
• Source stays at any. The docs: “Do not set a source port in a port forward or firewall rule unless you know you need it.”

A second public address needs a Virtual IP under Firewall > Virtual IPs first, or pfSense never answers ARP for it.

Check 5: the target host’s gateway

The one people skip. pfSense “must be the default gateway for the target host.” If 192.168.10.20 points at an old router at 192.168.10.254, the SYN arrives through pfSense, the SYN-ACK leaves through the other router, and the client discards it. From outside this is indistinguishable from a drop.

Fix the host’s gateway. If you cannot, the documented workaround is Firewall > NAT > Outbound in Hybrid mode with a LAN-interface rule translating any source to the LAN address for traffic to 192.168.10.20 port 8443. The host then replies to 192.168.10.1, and its logs lose the real client addresses.

Check 6: the host is not listening, or its own firewall is

From the LAN:

nc -vz -w 3 192.168.10.20 8443 || echo "service unreachable on the LAN"

If that fails, pfSense is not the problem. On the host, ss -ltnp shows what is bound to 8443 and on which address; a bind to 127.0.0.1 only is common. Windows Defender Firewall, ufw, firewalld and Docker’s published-port rules all sit in front of the service. Open the port rather than disabling the host firewall, and if you do disable it to isolate the fault, turn it back on before the next check.

Check 7: multi-WAN and reply-to

With two WANs, the docs say WAN rules “should NOT have a gateway set.” reply-to “ensures traffic leaves the same interface through which it arrived,” and a policy-routing gateway on the pass rule fights it. Leave Disable reply-to unticked under System > Advanced > Firewall & NAT, avoid floating rules for forwarded ports, and give every non-default WAN a gateway. The pfSense multi-WAN guide covers the gateway groups.

Check 8: something else owns the port

Status > UPnP IGD & PCP lists mappings clients created themselves; a console can claim TCP 443 first. Netgate’s own docs call UPnP “a potential security nightmare.” Leave it off unless one device needs it. Some residential ISPs also filter inbound ports; the documented test is forwarding an alternate external port such as 8080 or 18080 to internal 8443.

Check 9: making it work from inside

Once it works from outside, the LAN test still fails until you pick one of two options under System > Advanced > Firewall & NAT. NAT + Proxy reflection is TCP only and cannot cover ranges over 500 ports or more than 1000 ports total; Pure NAT handles any protocol. The docs prefer split DNS: a host override in Services > DNS Resolver resolving svc.example.com to 192.168.10.20 internally while public DNS returns 203.0.113.10. No hairpin, no port limits. The OPNsense port forwarding guide shows the same decision on OPNsense.

A target on a VLAN follows the same rules, and the inter-VLAN policy from the pfSense VLAN configuration guide must also allow it.

Things to test before you call it done

1. States. Diagnostics > States, filter on 8443. Per the states docs, “the destination section shows the translated destination and the original destination in parentheses.” An entry like 203.0.113.10:443 (192.168.10.20:8443) proves the redirect fired. No state means no rule passed it.
2. Capture WAN, then LAN. Diagnostics > Packet Capture wraps tcpdump and sees inbound traffic before the rule set. Seen on WAN but not LAN: NAT or rule. Seen on LAN with no reply: host or gateway.

tcpdump -ni igc0 tcp port 443 -c 20 || echo "capture failed on igc0"

3. Split DNS. dig +short svc.example.com @192.168.10.1 must return 192.168.10.20; the same query at 1.1.1.1 must return 203.0.113.10.
4. Outside again. Repeat the check 1 nc from cellular after every change; reflection working from the LAN proves nothing about the internet path.

If you skipped check 5 because the host “obviously” uses pfSense, run ip route on it. That is where most threads end.

Related across the network

• MikroTik Port Forwarding Not Working: Six Checks — mikrotikguide.com
• OPNsense Port Forwarding: NAT Rules That Actually Work — opnsenselab.com
• pfSense Slow Speeds: Find the Real Bottleneck — pfsenserouter.com
• UniFi vs pfSense: Which Firewall Fits Your Network? — firewallcompare.com
• Best Mini PC for pfSense Firewall: Hardware That Works — minilabhq.com