If a UniFi port forward fails externally, first compare the incoming WAN address with the public address used by the client. Double NAT needs a forward on the upstream router too; ISP CGNAT needs an inbound-capable service from the ISP. If the public address is on UniFi, correct the mapping and server return path below.
The UniFi WAN is behind another NAT
Open Settings → Internet, select the incoming WAN and read its IP address. If an upstream router performs NAT, also record the public address on that router; the external client must use that address.
| WAN situation | What it means for inbound traffic |
|---|---|
| Public address on UniFi WAN | Check the mapping on that WAN and any upstream filtering |
| Private address behind your own router | That router needs a matching forward or a supported bridge configuration |
| ISP CGNAT, often 100.64.0.0/10 | A UniFi forward cannot create the carrier-side inbound mapping |
| Dual WAN | Use the public address and rule binding for the same WAN |
Bridging your own modem does not remove ISP CGNAT. An address check exiting another WAN can also mislead the comparison. Port-forwarding reference.
Public WAN: correct the external port and internal destination
Open Settings → Policy Engine → Port Forwarding in Network 9.4, or Settings → Policy Table → Create New Policy → Port Forwarding in 9.3. Edit the existing forward or create a new named rule. Example: select the intended WAN, incoming TCP port 8443, From the permitted external source IP, forward address 10.42.30.20 and forward port 443, protocol TCP. Use the server’s reserved/static address. Save and check for another static or UPnP mapping using the same WAN/protocol/port.
From a permitted Windows LAN client, run Test-NetConnection 10.42.30.20 -Port 443 in PowerShell. TcpTestSucceeded: True confirms a TCP handshake; then open the service using its real HTTPS hostname. If TCP fails locally, inspect the server listener and host firewall before editing the forward. On a Linux server, ss -lnt must show LISTEN on 10.42.30.20:443 or the appropriate wildcard address, not only 127.0.0.1:443. Use the actual application protocol; this TCP example does not test UDP.
If the mapping looks correct, locate the missing SYN
For an authorized UniFi gateway SSH capture, run ip address show, match the WAN address noted above to its interface, and confirm the name in tcpdump -D. Use that interface in the gateway capture below.
Capture the WAN request and server reply
tcpdump -npi <wan-interface> -c 50 'tcp port 8443'Leave this capture running. In a second terminal, start a capture on the Linux service host before making the external connection:
sudo tcpdump -ni any -c 50 'tcp port 443'With both captures running, use PowerShell on a permitted Windows client outside the LAN: Test-NetConnection <wan-public-ip> -Port 8443. Replace the placeholder with the public address for this WAN. Read TcpTestSucceeded, then stop both captures with Ctrl+C. TCP Flags [S] identify a SYN request and [S.] a SYN-ACK reply.
If the WAN sees the SYN but the server does not, edit the matching forward with the fields above and correct any earlier conflicting mapping. Check the effective External-to-server-zone policy for translated destination 10.42.30.20:443.
If the server receives it, run ip route get <external-client-ip> there and read via and dev: the reply needs the gateway that performed NAT. Correct a conflicting host/VPN route if it selects another exit. Use the real client IP, not a sample public address.
Use fresh TCP sessions. Hardware-accelerated forwarding can limit gateway capture visibility; verify a missing packet at the endpoint or a port mirror before concluding the gateway dropped it.
Verify the external service
Open the service from the permitted external client using its HTTPS hostname and external port, for example https://service.example.com:8443 after replacing the hostname. Confirm the application works and that a new connection from an excluded source fails. Test LAN/hairpin access separately.