Police records must traverse a GRE path to a records annex, and confidentiality is required. Why combine IPsec with GRE rather than leaving GRE alone?
Select an answer to reveal the explanation.
Short Explanation
GRE gets the package across town; IPsec locks the package. Police records need that lock—otherwise the GRE envelope still shows the contents to anyone sniffing the underlay. Use both when you need overlay reachability plus confidentiality.
Full Explanation
Police records that must traverse a GRE path to a records annex with confidentiality required need more than GRE encapsulation. GRE alone moves the overlay package across the underlay but leaves contents exposed to anyone who can observe the path. Combining IPsec with GRE adds encryption and integrity to the GRE-encapsulated traffic so sensitive police records are not exposed in cleartext on the underlay while GRE continues to provide the overlay transport role between headquarters and the annex. IPsec does not remove the need for any tunnel source or destination addressing; endpoints and peer addressing remain part of tunnel and crypto design. GRE does not already encrypt, so IPsec is not merely a compressor for OSPF hellos—that misstates both technologies. Combining IPsec with GRE also does not force all traffic onto a single global VRF automatically; VRF membership is a separate routing-virtualization choice. Exam caveat: protect the right traffic selectors and confirm whether you encrypt GRE or run GRE over an IPsec tunnel—misordered or overly broad crypto ACLs can drop annex traffic or leave records cleartext. Operational check: bring up GRE between police HQ and the annex, apply IPsec to the GRE path, verify tunnel and IPsec SAs are up, and confirm a packet capture on the underlay shows encrypted payloads while records applications still reach the annex.