IPSec Tunnel is Up but Packet is Getting Dropped with Wrong SPI Counter Increase
Created On 09/25/18 19:10 PM - Last Updated 05/08/19 23:34 PM
- Phase 1 and Phase 2 are up for the IPSec tunnel, but packets are getting dropped somewhere.
- On the global counter output, any one of the following entries are incrementing at the same time:
- From the peer end, outbound traffic is working normally.
- In the ESP header, the sequence field is used to protect communication from a replay attack.
- If a packet arrives at the firewall and the difference of the sequence number with the previous packets is larger than the replay window size, then it will be considered as an attack and dropped by the firewall.
- This can happen when the connection is not stable or the packet does not arrive in order.
- The following CLI outputs show an example of the global counters with this issue:
> show counter global filter severity drop aspect tunnel category flow flow_tunnel_encap_err 38 0 drop flow tunnel Packet dropped: tunnel encapsulation error flow_tunnel_decap_err 705072 2 drop flow tunnel Packet dropped: tunnel decapsulation error flow_tunnel_encap_nested 38 0 drop flow tunnel Packet dropped: nested tunnel decapsulation flow_tunnel_ipsec_wrong_spi 705074 2 drop flow tunnel Packet dropped: IPsec SA for spi in packet not found
> show counter global filter severity drop aspect tunnel category flow flow_tunnel_natt_nomatch 11 0 drop flow tunnel Packet dropped: IPSec NATT packet without session SPI match
- Go to Network > IPSec Tunnels > General tab and disable 'replay protection' to resolve the issue.
- Click 'show advanced options' if this option is not displayed.
After 'replay protection' is disabled, the firewall will allow those packets even if their sequence number difference is larger than the replay window size.
Disabling 'replay protection' may cause the network to become vulnerable to replay attack.
This should be used with caution and applied only if no other solution is possible.
After disabling replay protection, if global counters still indicate the flow_tunnel_decap_err, then we will need to decrypt the IKE and ESP packets for further troubleshooting. Please reference the following article link for further guidance: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClinCAC