A port-forwarding rule on a home NAT router is correct, yet nothing outside can connect, and the router's WAN address is 100.64.12.9. Why, and what are the options?
answer
- look at the WAN address
- RFC 6598 shared space
- a NAT above your NAT
- the outer table has no entry
- PCP, IPv6, or go outbound
basics
~20 s100.64.12.9 is in 100.64.0.0/10, the shared space for carrier-grade NAT, so inbound packets stop at the ISP's NAT, which has no mapping toward you. Fix it with a public address, a mapping on the CGN, IPv6 or an outbound tunnel.
solid answer
~40 sRFC 6598 reserves `100.64.0.0/10` as Shared Address Space for the link between a subscriber and an ISP's carrier-grade NAT, so this router's WAN side is itself an inside address of another NAT. The internet sees the CGN's shared public address; an inbound packet arrives there, finds no mapping toward this subscriber and is dropped, so the correct home rule never sees traffic. The options are a public IPv4 address from the ISP; a mapping on the CGN itself, which RFC 6888 says a CGN MUST offer through a subscriber-control protocol that SHOULD be PCP, though the CGN picks the port; IPv6 with the CPE firewall opened; or an outbound tunnel to a host with a public address that relays clients in.
go deeper
Recall that 100.64.0.0/10 means an ISP NAT sits above your router, so a home forward alone cannot work.
Explain the inbound packet's path through two NATs, why the outer one drops it, and how to compare the WAN address with the externally seen address.
Lay out the options, public address, PCP on the CGN, IPv6 and an outbound relay, with what each needs and costs, and rule out double NAT, loopback and reply-path faults first.
Decide how a product that must accept inbound connections from home users should work when most of them may sit behind a CGN, rather than depend on forwards.
## The symptom The rule `TCP 8443 -> 192.168.1.10:443` is correct, the server answers on the LAN, and every outside attempt times out. The router's WAN interface shows `100.64.12.9`. That one number explains it. ## What 100.64.0.0/10 means RFC 6598 sets aside **`100.64.0.0/10`**, the addresses `100.64.0.0` to `100.127.255.255`, as **Shared Address Space** for the link between a subscriber's router and an ISP's **carrier-grade NAT** (CGN). An address there means the router's WAN side is itself an inside address of another NAT. Traffic leaves the home through two translations, the home router's and then the ISP's, and the address the internet sees belongs to the CGN and is shared with other subscribers. The same diagnosis applies when the WAN address is in an RFC 1918 range: another NAT, often the ISP's own modem, sits upstream. The quick test is to compare the router's WAN address with the address an external service reports for the connection; if they differ, there is a NAT above you. ## Why the forward never fires Follow an inbound packet: 1. A client sends to the **CGN's** public address on the port you advertised. 2. The CGN looks up its own table. It holds entries for flows your side started and for mappings someone explicitly created on it. Your home router's rule is not among them. 3. With no mapping, the CGN discards the packet or handles it according to its filtering behaviour. It never reaches `100.64.12.9`. The home rule is correct and irrelevant: it sits behind a translator that does not know about it. RFC 6269, on the problems of IP address sharing, says it directly: if a CGN is present, an incoming port must also be opened in the CGN, which makes subscribers dependent on their provider for this. ## The options | Option | What it needs | What you get | Cost | |---|---|---|---| | Public IPv4 from the ISP | the provider offers it | ordinary port forwarding again | often a paid extra | | Mapping on the CGN via PCP | CGN support, and a path for the request | an inbound mapping on the shared address | the CGN chooses the port | | IPv6 | IPv6 service and clients that have it | a global address per host, no translation | the CPE firewall must permit it; IPv4-only clients still cannot connect | | Outbound tunnel or relay | a host with a public address | works through any number of NATs | an extra hop; the relay carries your traffic | Detail on each: - **Public address.** The only option that restores a fixed well-known port on IPv4. RFC 6269 notes that on a shared address, inbound connections to well-known ports will not work in the general case. - **PCP.** RFC 6888, the CGN requirements, says a CGN MUST implement a protocol giving subscribers explicit control over NAT mappings and that it SHOULD be PCP (REQ-9). But a host's PCP server is by default its default router, which is the home router, so the request reaches the CGN only if the home router relays it upstream or the host is configured with the CGN as its server. RFC 6886 deliberately does not define how one NAT-PMP gateway would request a mapping from the next. Even when a mapping is granted, the CGN assigns the external port, so clients must learn it from a DNS SRV record, a URL with the port in it, or the application's own rendezvous. - **Port-range sharing.** Some sharing schemes give each subscriber a fixed block of ports. RFC 6269's example: you cannot open port 5002 for incoming connections if 5002 is not in your range. - **IPv6.** No translation is involved, but a typical home router blocks unsolicited inbound IPv6, so the "forward" becomes a firewall permission for that host and port, which PCP can also request. - **Tunnel or relay.** The server keeps an outbound connection to a machine with a public address, which accepts clients and sends their traffic down that connection. It works because every NAT on the path admits replies to a flow the inside started. ## Separating it from look-alike failures - **Double NAT you own**, your router behind your own modem's NAT: put the modem in bridge mode or forward on both devices. - **Works from outside but not from inside**: that is the router's loopback behaviour, not an upstream NAT. - **Requests arrive but replies are lost**: the server's default gateway is the suspect, not the ISP.
- If the ISP's carrier-grade NAT grants you external port 41000 through PCP, how do clients find the service?PCP only creates the mapping; it does not publish it. The service must advertise the shared address and port 41000 itself: in a URL with the port, in a DNS SRV record for protocols whose clients look one up, or through the application's own rendezvous server. A website on a non-standard port therefore needs the port in its links.
- Why does an outbound tunnel to a rented server work where every forwarding rule failed?Every NAT on the path creates a mapping for a flow the inside starts and admits that flow's return traffic. The tunnel is such a flow, so the rented server can push client traffic down it without any inbound mapping on the home router or the CGN. The price is an extra hop, the relay's bandwidth, and trusting the relay with the traffic.
saying these in an interview costs you the question
- 100.64.0.0/10 is just another RFC 1918 private range.
- The ISP's NAT forwards inbound packets to whichever subscriber router is listening.
- Enabling UPnP on the home router opens the port on the ISP's NAT too.
- Behind a carrier-grade NAT you can still choose to receive on port 443.
- IPv6 removes NAT, so inbound connections need no permission at all.