Firewall & NAT
The remote client normally does not need inbound port forwarding. The FRP server side still needs a reachable public entry point for control, enrollment, and published service ports.Topology A — server has a public IP
Direct defaults:Topology B — server is private behind a firewall
Example DNAT:203.0.113.10:8443, :9443 in this example), not the private server address.
Why published service ports should stay 1:1
Keeping public6001 -> internal 6001 means the product’s persistent reservation is also the port users actually connect to.
If an external firewall arbitrarily remaps every service port, the registry and Internet-facing endpoint stop matching, which makes operations and troubleshooting harder.
Who is responsible for what?
Hairpin NAT / split DNS
An internal user may fail to reachfw.example.com if that hostname resolves to the firewall’s public IP and the firewall does not support hairpin NAT.
If hairpin NAT is unavailable, use split DNS or another appropriate internal routing design.
Troubleshooting NAT
Check in this order:- public DNS/IP points to the correct firewall
- public control port DNATs to the expected server listen port
- public enrollment HTTPS DNATs correctly
- published service port stays open and preferably 1:1
- local
frpctl doctorreports a healthy topology - the client can reach the public endpoints from its own network