ISP modem drops UPnP NAT mappings after brief DSL SNR resyncs, breaking incoming services

Environment

Consumer DSL setup: ISP-supplied modem/router (firmware-controlled NAT) connected to an OpenWrt home router (routed mode) running miniupnpd. WAN link: ADSL/VDSL with occasional SNR fluctuations leading to brief resyncs. Services affected: home CCTV (ports 8443), self-hosted game server (UDP 27015).

Symptoms

From the internet, previously reachable services become unreachable after an overnight link blip; checking external port checkers shows ports closed. From LAN, services are up and listening. UPnP mappings seen in OpenWrt disappear after the modem reports a DSL retrain; mappings only restore after a modem power-cycle or manual re-request from the internal client.

Observations

OpenWrt syslog shows miniupnpd errors around the time of the DSL resync: 'upnp: IPv4 gateway changed' and subsequent removal of all mappings. The ISP modem web UI shows a short DSL resync (seconds) and internal NAT session table flushes; WAN IP remained the same after resync. Manually reissuing a UPnP mapping (from the host) restores the mapping immediately and services are reachable again until next resync. No CGNAT visible from repeated external checks (public IP matches ISP portal).

Already attempted

Upgraded miniupnpd package to latest stable on OpenWrt; bound UPnP to the WAN interface explicitly; tried to set modem to bridge mode but the ISP portal did not allow it; created a cron job to reapply mappings after detecting WAN flaps. Replaced Ethernet cable between modem and router. Symptoms persist: mappings still disappear on modem-triggered resyncs.

Question

Why do UPnP mappings vanish when the DSL link briefly resyncs even if the WAN IP does not change, and what is the safest way to make inbound ports persist across short link disruptions without needing daily manual reconfiguration or a modem power-cycle?

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

ISP modem performs an internal NAT or firewall restart during DSL resyncs, flushing UPnP/NAT state even when WAN IP unchanged. 90%

Modem firmware bug that resets NAT/UPnP state on physical link retrain rather than preserving sessions. 85%

miniupnpd-created mappings are only local to the OpenWrt router; the ISP modem sits in front doing NAT and drops its own mapping table on resync (double NAT scenario). 70%

Summary

UPnP is designed to create dynamic NAT mappings tied to the perceived gateway or NAT state. When the ISP modem experiences a link resync it typically rebuilds its internal NAT/session tables or may restart the NAT function even if the external IP is unchanged. That invalidates any UPnP state maintained by downstream routers. If the modem is performing NAT (double NAT), it owns the external mapping and may not preserve mappings across internal resets. OpenWrt/miniupnpd can only create mappings on the device that terminates the public IP; if the ISP modem/router is doing NAT, mappings created on the OpenWrt box may not be reflected/retained by the modem.

Suggested Fixes

Diagnostic step 1

Determine path of NAT: put modem into bridge mode if the ISP supports it so OpenWrt receives the public IP directly; this removes double NAT and allows persistent static port forwarding on OpenWrt. If bridge mode is unavailable, request ISP support to enable bridge/DMZ mode or persistent NAT behavior — escalate to ISP with logs showing mapping loss.

Diagnostic step 2

Configure static port forwarding on the device that owns the public IP (ISP modem) rather than relying on UPnP. This is the most reliable approach and survives link resyncs because static rules are persisted across restarts.

Diagnostic step 3

If static forwarding on modem is impossible, implement a resilient reverse-tunnel (reverse SSH or a small rendezvous server/NGROK-style service) from a LAN host to an external host to accept inbound connections without relying on UPnP. This avoids modifying modem state and is reversible by stopping the tunnel.