A grain-elevator auditor rejects the VPN gateway’s default IPsec/IKE proposal as a legacy cipher set. What should the security engineer apply on the site-to-site connection?
Select an answer to reveal the explanation.
Short Explanation
Default VPN proposals are the factory combo meal—auditors want the chef’s special. Slap a custom IPsec/IKE policy on the connection with IKEv2 and modern crypto instead of shrugging that “VPN equals done.”
Full Explanation
Azure VPN Gateway site-to-site connections can use a custom IPsec/IKE policy so auditors can reject weak default proposals and require IKEv2 with stronger encryption and integrity algorithms. For the grain-elevator auditor who rejects the default cipher set, attach a custom IPsec/IKE policy on the site-to-site connection that specifies the stronger algorithms the municipality accepts, and ensure the on-premises device mirrors that policy.
Leaving the default proposal because “any VPN is encrypted enough” fails the auditor’s cipher requirement. Replacing the VPN gateway with ExpressRoute private peering and assuming MACsec is included automatically fails: ExpressRoute privacy is not default encryption, and MACsec applies to ExpressRoute Direct ports—not as an automatic substitute for fixing VPN proposals. Disabling IPsec and relying only on an NSG Allow for the yard public IP fails confidentiality entirely.
Exam caveat: both peers must agree on the custom policy or the tunnel will not establish. Operational check: apply the custom policy, bring the tunnel up, verify negotiated algorithms match the standard, and store the cipher baseline in the municipal crypto standard. In municipal Azure estates, document the decision in the change record, validate with a nonproduction rehearsal, and confirm monitoring still pages the on-call operator when the control fails closed during an incident drill.