> Source: [sk165773](https://support.checkpoint.com/results/sk/sk165773) # sk165773 - VPN instability on 1400 Security Gateway using DAIP | Property | Value | |----------|-------| | Solution ID | sk165773 | | Date Created | 2020-03-16 | | Last Modified | 2020-03-18 | | Technical Level | Advanced | | Products | Spark Firewall (Locally Managed) | | Versions | R82.00.X, R81.10.X | | OS | Gaia | ## Symptoms - * Periodically, VPNs to some of the DAIP Gateways go down. In order to reestablish them the DAIP Gateways must be rebooted. The user has observed the following behavior: * When a 1430 appliance loses its Internet connection (and therefore also the VPN connection), then the Internet connection is up again and the 1430 appliance receives a new public IP address from its Internet router, and the VPN tunnel is automatically reestablished. * When a 1430 appliance loses its Internet connection (and therefore also the VPN connection), then the Internet connection is back again and the 1430 appliance keeps its old public IP address. The VPN tunnel is **not** automatically reestablished and the appliance has to be rebooted for the VPN tunnel to come up again. * When the VPN connection is lost, the following error message appears in the log encryption failure: `Unknown SPI: 0x9a43997d for UDP encapsulated IPsec packet.` * The instructions in Scenario # 5 in [sk108600](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk108600) (dpd mode, central GW - HQ) do not resolve the issue. * VPN Kernel Debug shows: ``` (kernel traps vpnd to ask for an SPI/phase 2)) [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][VPNIO] vpn_trap_multik: called from kernel instance 1. type = 4 [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][VPNIO] fwrand_exchange_with_kernel_multik: called. kernel_instance = 1, is_ipv6kernel = 0 [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50] hash_drbg_add_sample: Adding 40 bytes worth 4000 milibits. Total: 92000. Required: 0 [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][stat] vpn_inc_status_VPND_counter: increased counter 16 [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][VPNIO] vpn_trap_multik: received SPI_NOTIFY [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][tunnel] vpn_ipsec_spi_notify:: instance: 1, spi 0, 127.0.0.1, peer 0.0.0.1, proto 50, my range 172.16.10.0-172.16.10.255, peer range 192.168.87.0-192.168.87.255, user md 0000000000000000, methods 111 0, packetID 0, proto 0 ports 0 0 [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][tunnel] 0 ac197c14 <172.16.10.1 port 1, 192.168.87.1 port 0, 1> [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50] kmsg_read_local: 1 kmsgs handled ... [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][tunnel] < FWIKE_ROLE_START > Id = 26 [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][tunnel] < FWIKE_ROLE_INITIATOR > Id = 26 [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][tunnel] ike_initiator: entering with my_instance: 1 [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][tunnel] ike_initiator: notifyData.notifyType = 0 [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][tunnel] InitiatorOnEnter: idRanges USED mine [ac100a00-ac100aff] peer's [c0a85700-c0a857ff] [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50] GetEntryIsakmpObjectsHash: received ipaddr: 0.0.0.1 as key, found fwobj: syd [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50][tunnel] peer_ip_is_mobile: Host at 0x00000001 is NOT mobile [vpnd 5811 4093732768]@twenty[26 Feb 16:07:50] find_sa_by_ike_peer: Find IKE SA for IKE peer <0.0.0.1,00000000000000 ``` * ``` The below vpnd has sent an ioctl to kernel regarding the established SPI: (calc_tunnel_instance puts it on instance 1, which is what causes the breakage because 1 doesn't have the orig_route_params with the relevant NAT-T port..) @;20597;26Feb2020 16:07:50.061380;[cpu_1];[fw4_0];fwmultik_cache_add_or_cache : calling callback (table : meta_sas). create_new_MSA: Tunnel Params = peer: 0.0.0.1, methods: (ESP Tunnel AES-128 SHA1), IDs: [172.16.10.0/24]<-->[192.168.87.0/24]; @;20597;26Feb2020 16:07:50.061385;[cpu_1];[fw4_0];calc_tunnel_instance: Tunnel Params = peer: 0.0.0.1, methods: (Tunnel 3DES MD5), IDs: [172.16.10.0/24]<-->[192.168.87.0/24]; @;20597;26Feb2020 16:07:50.061388;[cpu_1];[fw4_0];calc_tunnel_instance: hash 397074425, instance 1/2; @;20597;26Feb2020 16:07:50.061390;[cpu_1];[fw4_0];create_new_MSA: MSA for IPsec, will belong to instance 1, VPN acceleration was switched off; @;20597;26Feb2020 16:07:50.061392;[cpu_1];[fw4_0];ld2_in: d=7952 lp=local_meta_sas tuple=<800005>; @;20597;26Feb2020 16:07:50.061394;[cpu_1];[fw4_0];ld2_in: result=0; @;20597;26Feb2020 16:07:50.061395;[cpu_1];[fw4_0];fwmultik_cache_table_global_obtain_lock : fwmultik_cache_table_in is obtaining global lock for table meta_sas. entered with ref = 1 ; @;20597;26Feb2020 16:07:50.061398;[cpu_1];[fw4_0];kiss_htab_in: "meta_sas":11 not found <800005>; @;20597;26Feb2020 16:07:50.061400;[cpu_1];[fw4_0]; ; @;20597;26Feb2020 16:07:50.061401;[cpu_1];[fw4_0];fwmultik_cache_table_global_release_lock : global lock for table meta_sas is being released. entered with ref = 2 ; ... (MSPI created, curious about persistent_tunnels_ranges - wondering if it could be used to always establish this Phase 2) @;20597;26Feb2020 16:07:50.061404;[cpu_1];[fw4_0];create_mspi: --- NEW MSPI === 800005 (i: 1) (generated in 1 iteration(s)); @;20597;26Feb2020 16:07:50.061408;[cpu_1];[fw4_0];ld_getid: find persistent_tunnels_ranges: ld2_get_wto_ttl_aggr: d=8114 lp=tab_name_table tuple=<73726570,657473 ``` ## Cause The calc_tunnel_instance ends up sending the new SPI to an instance different from the one that handled the initial tunnel from the DAIP peer. The other instance does not have the entry in the orig_route_params. As a result, it sends to port 4500 because it is not aware of the NAT port.
## Solution This solution requires authentication. Please log in to view the full solution. --- # Agent Instructions This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products. ## Navigating This Knowledge Base - **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt) - **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml) - **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}` - **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content