A plant's Site-to-Site VPN tunnel shows UP on the AWS side and down on the on-premises firewall. The firewall's Phase 2 traffic selector does not match the networks the VPN is set to carry. What should change?
Select an answer to reveal the explanation.
Short Explanation
One side of a handshake cannot agree to carry mail the other side never put on the list. You align the firewall's Phase 2 traffic selector so both sides negotiate the same traffic. A new pre-shared key or a shorter IKE lifetime does not fix a selector that does not match, and a network ACL does not negotiate the tunnel.
Full Explanation
Phase 2 of the VPN negotiates the traffic selector, the set of networks the IPsec association will carry. The plant's firewall proposes a selector that does not match the networks configured on the AWS VPN, so the two sides do not agree and the tunnel is not up on both ends. Aligning the firewall's Phase 2 selector with the VPN lets both sides negotiate the same traffic. The AWS side already shows the tunnel UP, which means the Phase 1 exchange, including the pre-shared key, has succeeded. Replacing the key is the fix for a key mismatch, not for a selector mismatch, and a wrong new key would break the side that is already up. Network ACLs filter packets inside the VPC after traffic exists. They do not change the selector the firewall proposes, and opening them does not make the firewall mark the tunnel up. Shortening the IKE lifetime renegotiates Phase 1 on a different timer. It leaves the Phase 2 selector untouched. Caveat: both directions of the selector have to match, and routes still have to exist before hosts can pass traffic. Operational check: after the selector matches, confirm the firewall shows the tunnel up and pass a test packet both ways.