300-730 · Question #53
Refer to the exhibit. An engineer is troubleshooting a new GRE over IPsec tunnel. The tunnel is established but the engineer cannot ping from spoke 1 to spoke 2. Which type of traffic is being…
The correct answer is A. ESP packets from spoke2 to spoke1. With the GRE over IPsec tunnel already established, failed pings from spoke1 to spoke2 indicate that return ESP traffic from spoke2 to spoke1 is being blocked.
Question
Options
- AESP packets from spoke2 to spoke1
- BISAKMP packets from spoke2 to spoke1
- CESP packets from spoke1 to spoke2
- DISAKMP packets from spoke1 to spoke2
How the community answered
(24 responses)- A58% (14)
- B17% (4)
- C21% (5)
- D4% (1)
Why each option
With the GRE over IPsec tunnel already established, failed pings from spoke1 to spoke2 indicate that return ESP traffic from spoke2 to spoke1 is being blocked.
Because the IPsec tunnel is established, IKE negotiation succeeded and the issue lies with encrypted data traffic. The ICMP request from spoke1 reaches spoke2 successfully as ESP, but the ICMP reply encapsulated in ESP from spoke2 back to spoke1 is dropped - most likely by an ACL on spoke1 or an intermediate device that does not permit inbound ESP from the spoke2 peer address.
ISAKMP traffic is used only during IKE tunnel negotiation; since the tunnel is confirmed established, ISAKMP is not the source of the ping failure.
If ESP from spoke1 to spoke2 were blocked, spoke2 would never receive the encapsulated ICMP request, but the scenario implies the request reaches spoke2 since only the reply fails.
ISAKMP from spoke1 to spoke2 handles tunnel establishment, not data forwarding; the fact that the tunnel is already up confirms this path is functioning correctly.
Concept tested: GRE over IPsec asymmetric ESP return traffic blocking troubleshooting
Source: https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25261-gre-outside-asa.html
Topics
Community Discussion
No community discussion yet for this question.