A public-health department runs DMVPN over Internet underlays carrying citizen health records between clinics and HQ. Why is IPsec commonly bound to the DMVPN tunnels?
Select an answer to reveal the explanation.
Short Explanation
Internet underlay is a public hallway—IPsec is the sealed envelope around the GRE tunnel. Health records should not ride as postcard-readable cleartext. Bind IPsec so the overlay stays confidential on that underlay.
Full Explanation
A public-health department running DMVPN over Internet underlays that carry citizen health records binds IPsec to the tunnels so the GRE/mGRE overlay is encrypted and authenticated. The underlay is untrusted public IP; without IPsec, GRE payloads can be inspected or altered in transit. IPsec does not replace DMVPN’s NHRP or routing functions—it protects the overlay packets those functions create. For regulated civic data, tunnel protection is the expected security control on Internet DMVPN.
IPsec does not replace NHRP registration or eliminate the need for an NHS; spokes still register NBMA mappings. IPsec does not distribute LDP transport labels across a provider P core—that belongs to MPLS, not DMVPN crypto. IPsec also does not force all spoke-to-spoke traffic to remain hairpinned forever; with proper NHRP shortcut behavior, encrypted spoke-to-spoke tunnels can form.
Exam caveat: “DMVPN up” is incomplete if the design requires protection and IPsec SAs are down—treat crypto as a prerequisite for secure overlay use. Operational check: verify tunnel protection ipsec profile on mGRE interfaces, confirm IPsec SAs are QM_IDLE/active to the hub (and shortcut peers if used), and only then validate NHRP mappings and health-record application flows across the overlay.