UPnP port mappings vanish after ISP modem reboot despite static DHCP lease and fixed WAN IP

Environment

Home network with ISP‑supplied modem/router (gateway mode), internal router behind modem in DMZ, internal services use static DHCP reservations on internal router; modem reports public IP unchanged after reboot.

Symptoms

Services hosted on internal router (game server on UDP 27015, SSH on TCP 2222) become unreachable from the internet immediately after ISP modem reboots. Internal router still shows UPnP mappings present, but external port scan from cloud host shows ports closed.

Observations

After modem reboot the router's UPnP client reports mappings active; WAN side traffic captured on internal router shows no external SYN/UDP reaching WAN port. Modem's web UI shows UPnP entries recently created by internal router, but modem's routing table shows no NAT translation for those ports. Modem logs include a DHCP lease renewal entry for the internal router but no kernel NAT errors. External traceroute to public IP reaches modem then stops; performing a tcpdump on modem (when accessible) shows no forwarded packets to the claimed mapped ports.

Already attempted

Restarted internal router (power cycle and software restart), re-created static port forwards manually on modem UI, disabled UPnP on internal router and configured static NAT on modem, swapped internal router to pass-through/bridge mode temporarily — mapping persisted only when modem was the NAT device; contacted ISP support who confirmed modem restarted normally and WAN IP unchanged but declined to run NAT debug.

Question

Why are UPnP-created mappings visible in the modem and internal router UIs yet external connections to those ports are blocked after the modem reboots, and what reversible diagnostics and mitigations can restore persistent external reachability without requiring ISP firmware changes?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Modem firmware bug: UPnP entries stored in config but not applied to kernel NAT table after reboot. 90%

Race condition where modem applies firewall policy before applying UPnP/NAT rules, dropping inbound packets until mappings are reasserted. 60%

Modem treats DMZ/bridge mode inconsistently across reboots, causing stale route or ARP entry that prevents packet forwarding even though mapping exists in UI. 50%

Summary

Symptoms point to the modem acting as the authoritative NAT and not applying or not honoring the translation chains after a reboot even though the UPnP lease entries are parsed and displayed. Two likely interaction patterns cause this: (1) the modem's UPnP implementation stores requested mappings but fails to install kernel NAT rules until an internal event (e.g., refresh or external packet) occurs; (2) the modem's upstream NAT or firewall policy is applied before the internal NAT table reconciliation, blocking inbound traffic until mappings are reasserted. The fact that switching the internal router into bridge mode makes port forwarding work indicates the modem is the bottleneck. The modem showing the public IP unchanged rules out dynamic IP-based filtering as the root cause.

Suggested Fixes

Diagnostic step 1

Temporarily place internal router in true bridge/pass-through mode so the internal router is the single NAT device; verify external ports become reachable. If this restores reachability, continue using bridge mode or ask ISP to support a modem in passthrough.

Diagnostic step 2

Capture packet traces on both modem and internal router during an external connection attempt (tcpdump on internal router WAN interface and, if possible, modem packet capture) to confirm whether inbound packets reach the modem and whether they are forwarded. Save captures and only share with ISP support if comfortable.

Diagnostic step 3

Use a controlled test from a cloud host (single TCP connect or UDP probe) while iterating: (a) create mapping, (b) reboot modem, (c) immediately trigger an external probe to see if first packet is dropped and whether a subsequent probe succeeds; document timing to expose race conditions.