Support Center > Search Results > SecureKnowledge Details
After Cluster Failover, IKEv2 VPN tunnel down and SmartView Tracker log shows following error "Unknown SPI for IPsec packet"
Symptoms
  • After Cluster Failover, VPN tunnels go down and the following error is shown in the SmartView Tracker log: "Unknown SPI for IPsec packet"
  • The Output of fw tab -t vpn_queues -s shows that the number of entries reached its limit. As a result, new SAs cannot be saved. This causes a VPN outage: For example: In a VSX environment, the default vpn_queues kernel table limit is 1200 entries:
    [Expert@VSX]# fw tab -t vpn_queues -s
    HOST                  NAME                               ID #VALS #PEAK #SLINKS
    localhost             vpn_queues                        428  1200  1200       0
    On a Security Gateway/Cluster, the default vpn_queues table limit is 30600 entries:
    [Expert@Member1]# fw tab -t vpn_queues -s
    HOST                  NAME                               ID #VALS #PEAK #SLINKS
    localhost             vpn_queues                        428  30600  30600       0
  • Rebooting the Cluster Member/VSX solves the issue temporarily.
Cause

Background: On the Gateway/Cluster Object, a VPN community is set to support Ikev2, or use Ikev2 protocol for the tunnel establishment.

On the standby member, vpn_queues table grows disproportionally to the number of IKE and IPSec SAs, eventually causing the vpn_queues kernel table to become full. No new SAs can be stored in the kernel table.

When the initial IKE SA entry is synced, new_ike_sa will create new ike2esp queues for each update to the entry, as if there is no ike2peer mapping.
ike2peer mapping is not created until IKEV2_SA_ESTABLISHED is set in the flags. This results in 4 extra queues for each IKE SA that is not freed.

For Example:

First update with new IKE SA cookies from active member:

[vs_6];[tid_0];[fw4_0];SET: id=466(ikev2_sas) keys(4)=<7d8fed5d,4be208e8,d022c9d0,bcb0968> vals(6)=<6c9d7004,0,d5ef4cb,0,0,0> refresh time=10800 aggressive time=0 time to live=0 sync time=1 given kmask=0 op_code=0 no n6addrs given;
[vs_6];[tid_0];[fw4_0];Queue 14794 has 0 elements; allocated size = 3 (max = 0);
[vs_6];[tid_0];[fw4_0];Queue 14795 has 0 elements; allocated size = 3 (max = 0);
[vs_6];[tid_0];[fw4_0];ld2_set_wto_ttl_aggr: d=429 lp=ike2esp tuple=<7d8fed5d,4be208e8,d022c9d0,bcb0968;39ca,39cb@(0)> flags 0 opcode 0;

Next time new queues are created, overwriting existing values for these cookies in ike2esp

[vs_6];[tid_0];[fw4_0];SET: id=466(ikev2_sas) keys(4)=<7d8fed5d,4be208e8,d022c9d0,bcb0968> vals(6)=<a0790004,0,d5ef4cb,0,0,0> refresh time=10800 aggressive time=0 time to live=0 sync time=2 given kmask=1 op_code=0 no n6addrs given;
[vs_6];[tid_0];[fw4_0];Queue 14796 has 0 elements; allocated size = 3 (max = 0);
[vs_6];[tid_0];[fw4_0];Queue 14797 has 0 elements; allocated size = 3 (max = 0);
[vs_6];[tid_0];[fw4_0];ld2_set_wto_ttl_aggr: d=429 lp=ike2esp tuple=<7d8fed5d,4be208e8,d022c9d0,bcb0968;39cc,39cd@(0)> flags 0 opcode 0;

Third time, IKEV2_SA_FLAGS_PEER_ESTABLISHED is set (the "8" in the value second field), so this is the last time queues are created for these cookies:

[vs_6];[tid_0];[fw4_0];SET: id=466(ikev2_sas) keys(4)=<7d8fed5d,4be208e8,d022c9d0,bcb0968> vals(6)=<6ca85804,8,d5ef4cb,0,0,0> refresh time=10800 aggressive time=0 time to live=0 sync time=2 given kmask=1 op_code=0 no n6addrs given;
[vs_6];[tid_0];[fw4_0];Queue 14798 has 0 elements; allocated size = 3 (max = 0);
[vs_6];[tid_0];[fw4_0];Queue 14799 has 0 elements; allocated size = 3 (max = 0);
[vs_6];[tid_0];[fw4_0];ld2_set_wto_ttl_aggr: d=429 lp=ike2esp tuple=<7d8fed5d,4be208e8,d022c9d0,bcb0968;39ce,39cf@(0)> flags 0 opcode 0;


Solution
Note: To view this solution you need to Sign In .