A manufacturing customer connects its data center FTD, which has a static public address, to a supplier's firewall that also has a static public address. The supplier contract requires IKEv2 with a pre-shared key, and reachability through the tunnel must be limited strictly to the data center's 10.20.0.0/24 application subnet. Which site-to-site VPN configuration meets every condition?
Select an answer to reveal the explanation.
Short Explanation
Set up an IKEv2 site-to-site VPN with a pre-shared key and matching proxy IDs for 10.20.0.0/24 on both ends. They’re like a key that opens only the application subnet’s door, keeping tunnel traffic within the required range.
Full Explanation
A site-to-site tunnel is negotiated between two appliances and then carries only the traffic selectors both peers agree on, and those proxy IDs are what keep reachability inside the contract. Declaring 10.20.0.0/24 on both ends brings the tunnel up while every other network pair is refused during phase two, and the IKEv2 plus pre-shared key requirement fixes the exchange version at the same time. Advertising all internal routes still builds a valid IKEv2 tunnel with the same key, but it hands the supplier far more reachability than the clause allows, so that design fails the subnet restriction. An IKEv1 connection with identical proxy IDs matches the reachability limit exactly yet negotiates the older exchange version. A remote access profile with IKEv2, a pre-shared key and a subnet restriction still authenticates a user client rather than a firewall appliance, so it never forms the device-to-device link between the two sites. Exam caveat: proxy identifiers must match on both peers or the tunnel drops during negotiation. Practical check: confirm the phase two proposal shows the single subnet and verify that a packet to any other internal network is carried outside the tunnel.