A housing authority spoke stops registering to the DMVPN hub after the branch firewall’s NAT pool changes. What registration detail should engineers verify first?
Select an answer to reveal the explanation.
Short Explanation
When the firewall’s public face changes, the spoke’s “home address on the Internet” changes too. NHRP registration and NAT-T have to advertise that new NBMA mapping—old pool leftovers leave the hub staring at a ghost.
Full Explanation
DMVPN spokes behind NAT register an NBMA address that must reflect the currently mapped public address the hub can reach. After a housing-authority branch firewall’s NAT pool changes, engineers should verify that NHRP and IKE still advertise the spoke’s current public mapped address and that NAT-T keeps UDP 4500 open through the new pool. Stale mappings leave the hub pointing at a ghost address.
OSPF network type flips after a NAT change are unrelated first checks for registration failure. Assuming the hub crypto ACL must mirror the old public address instead of dynamic mapping often fights DMVPN’s dynamic model. VTP pruning on campus access switches behind the spoke does not fix spoke-to-hub NHRP registration over the underlay.
Exam caveat: NAT pool change → update/verify NBMA registration and NAT-T path first.
Operational check: clear stale NHRP/IPsec state, confirm new public mapping in registration, test UDP 4500 through the firewall, and re-register the housing spoke to the hub. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services.