topic Re: Understanding a kernel vpn debug in Firewall and Security Management

Understanding a kernel vpn debug

ibrown — Wed, 28 Jan 2026 10:45:29 GMT

Good morning all.

I've got a repeating vpn issue between my R81.20 cluster and a 3rd party cisco gateway. It fails to re-negotiate on the phase 2 timeout without me resetting the vpn at the CP end.
I've checked with the the 3rd party and the ikev2 vpn settings all match, but it still fails.

I've taken a kernel debug with the instructions here https://support.checkpoint.com/results/sk/sk180488 but I'm not totally sure how to interpret the debug output, anyone got any pointers to help read through it to isolate the issue ?

Thank you

Ian

Re: Understanding a kernel vpn debug

Vincent_Bacher — Wed, 28 Jan 2026 11:00:02 GMT

It's difficult to answer this without seeing the debug output.

Re: Understanding a kernel vpn debug

AttiqRahman786 — Wed, 28 Jan 2026 11:16:50 GMT

For Phase 2 issues, mostly they are related to Encryption Domains. Do they match on Cisco? normally they have to add policy rules to allow the same domains.

Re: Understanding a kernel vpn debug

israelfds95 — Wed, 28 Jan 2026 11:21:35 GMT

We need a bit more information to assist you, as there are several possible causes for this issue. Please let us know:

How your Link Selection settings are configured
Whether you are using ISP Redundancy
Details about the VPN community configuration and relevant security rules, and informations phase 1 and phase 2 from remote peer

Based on your description, it seems Phase 1 is established, but Phase 2 fails to re-negotiate after the timeout. Since you have already verified the IKEv2 settings on both sides, let's gather more diagnostic information.

Recommended Steps

Collect VPN Debugs:

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SitetoSiteVPN_AdminGuide/Content/Topics-VPNSG/CLI/vpn-debug.htm?tocpath=Command%20Line%20Reference%7Cvpn%7C_____6
```
vpn debug on
vpn debug trunc on
vpn debug ikeon
vpndebug trunc ALL=5
```
(Remember to disable debug after collecting logs to avoid performance impact:vpn debug off, vpn debug ikeoff, vpn debug truncoff
Analyze with IKEView - sk30994:
- Download IKEView (see: What is the IKEView utility?)
- Use it to analyze the debug files for detailed IKE negotiation information.
Reference Best Practices:
- Review sk108600 – VPN Site-to-Site with 3rd party for common issues and solutions when working with third-party devices.
- This sk normally bring good solutions for many situations
Check SmartConsole Logs:
- Filter by the peer’s public IP to find relevant VPN log entries.

Next Steps

Please provide:

The debug logs collected
Details about your Link Selection, ISP Redundancy, and VPN community configuration

With this information, we can help you isolate the root cause and suggest a solution.

If this is a critical situation for your environment, I suggest opening a TAC (Technical Assistance Center) case with Check Point Support to ensure faster and more direct assistance.

Best Regards,

Re: Understanding a kernel vpn debug

Tal_Paz-Fridman — Wed, 28 Jan 2026 11:28:53 GMT

I would also add the ATRG: VPN Core (Site to Site)

https://support.checkpoint.com/results/sk/sk104760

Re: Understanding a kernel vpn debug

ibrown — Wed, 28 Jan 2026 11:33:53 GMT

Agreed, not sure how much to post without exposing too much. Here is a redacted snippit where it fails.

Re: Understanding a kernel vpn debug

CaseyB — Wed, 28 Jan 2026 14:36:12 GMT

Do you see any logs using:

blade:VPN AND <Cisco-Public-IP> AND action:Reject

Re: Understanding a kernel vpn debug

Vincent_Bacher — Wed, 28 Jan 2026 19:43:45 GMT

As I am limited to my mobile at the moment my observation is not really safe. From my perspective the debug shows no kernel-level packet drops. Data traffic is fully accelerated by SecureXL (SXL).

The issue seems to be a missing Outbound IPsec SA (Phase 2). While inbound traffic is successfully decrypted, the gateway cannot encrypt return traffic because the outbound SPI (MSPI) is missing, forcing a tunnel trigger. IKE negotiation packets are correctly forwarded to the iked daemon.

Key Log Evidence

• Offloading: Tunnel (5ae8 (i: 0)) handled by SXL. [span_5](start_span)Preparing..

• The Error: request_to_open_tunnel_if_not_ready: no mspi --> no VPN on this side (dir 2)

• IKE Success: vpnk_multik_forward_vpnxl: ... forwarding to global instance

Conclusion

The firewall kernel is functioning correctly. The failure is located in the VPN Phase 2 negotiation within the user-mode process, resulting in unidirectional SAs (Inbound OK, Outbound missing).

Next Step

Investigate $FWDIR/log/ike.elg for Phase 2 negotiation errors (e.g., No Proposal Chosen, TS Mismatch) and verify current SAs using vpn tu.

And in addition check logs on peer gateway at if I an right it should show the reason for a phase 2 negotiation issue.

but please be aware that I could have missed or misinterpreted something on my mobile display.

Re: Understanding a kernel vpn debug

the_rock — Wed, 28 Jan 2026 20:26:41 GMT

I wonder if its nat issue?

What are enc domains? Is it using empty group as enc domains? Also, perment tunnel and how is tunnel mgmt set up?

Is nat disabled inside community?

12:46:49.565629;[cpu_3];[fw4_0];IKE_Utils_FillIKEInfo: outgoing_single_IP = 0.0.0.0 and peer_IP = my_external_IP;
@;2551617668.10148319;21Jan2026 12:46:49.565630;[cpu_3];[fw4_0];IKE_Utils_FillIKEInfo: pIKEInfo printout for cookies <8bd665d5f3c76d98 : 3be797e83a56fe7c>;
@;2551617668.10148320;21Jan2026 12:46:49.565631;[cpu_3];[fw4_0];IKE_Utils_FillIKEInfo: pIKEInfo->m_stateRestored = 1;
@;2551617668.10148321;21Jan2026 12:46:49.565631;[cpu_3];[fw4_0];IKE_Utils_FillIKEInfo: pIKEInfo->m_myAddress = my_external_IP;
@;2551617668.10148322;21Jan2026 12:46:49.565632;[cpu_3];[fw4_0];IKE_Utils_FillIKEInfo: pIKEInfo->m_myPort = 500;
@;2551617668.10148323;21Jan2026 12:46:49.565633;[cpu_3];[fw4_0];IKE_Utils_FillIKEInfo: pIKEInfo->m_peerAddress = thirdparty_IP;
@;2551617668.10148324;21Jan2026 12:46:49.565633;[cpu_3];[fw4_0];IKE_Utils_FillIKEInfo: pIKEInfo->m_peerPort = 500;
@;2551617668.10148325;21Jan2026 12:46:49.565634;[cpu_3];[fw4_0];IKE_Utils_FillIKEInfo: pIKEInfo->m_throughIf = 13;
@;2551617668.10148326;21Jan2026 12:46:49.565634;[cpu_3];[fw4_0];IKE_Utils_FillIKEInfo: pIKEInfo->m_NATT_probing = 0;
@;2551617668.10148327;21Jan2026 12:46:49.565635;[cpu_3];[fw4_0];IKE_Utils_FillIKEInfo: setting entry in dynamic_ipsec_source_address table;
@;2551617668.10148328;21Jan2026 12:46:49.565637;[cpu_3];[fw4_0];get_ike_SEP_ownership: entering;
@;2551617668.10148329;21Jan2026 12:46:49.565641;[cpu_3];[fw4_0];vpn_translate_dst_cpip: Entering with dst: 253.116.23.193;
@;2551617668.10148330;21Jan2026 12:46:49.565643;[cpu_3];[fw4_0];vpn_translate_udp_dst_src: src=0.0.0.0, dst = my_FW_IP, sport 0, dport 0;
@;2551617668.10148331;21Jan2026 12:46:49.565645;[cpu_3];[fw4_0];vpn_translate_udp_dst_src: not invalidating chain cache in inbound;
@;2551617668.10148332;21Jan2026 12:46:49.565645;[cpu_3];[fw4_0];vpn_translate_udp_dst_src: succeeded to translate;
@;2551617668.10148333;21Jan2026 12:46:49.565647;[cpu_3];[fw4_0];get_address_for_iked_assignment: enter for peer address thirdparty_IP, might be daip 1, might be ra 0, user MD: 0;
@;2551617668.10148334;21Jan2026 12:46:49.565649;[cpu_3];[fw4_0];get_address_for_iked_assignment: returning canonized address: thirdparty_IP;
@;2551617668.10148335;21Jan2026 12:46:49.565651;[cpu_3];[fw4_0];get_iked_handler_for_address: dae

Re: Understanding a kernel vpn debug

the_rock — Thu, 29 Jan 2026 00:05:08 GMT

I just ran whole debug through ms copilot AI and it pretty much referenced what I asked about, vpn domains. Here is what I would do to try fix this. Set BOTH enc domains for this community to empty groups, set tunnel mgmt per gateway and permanent tunnels, but make sure rule reflects actual subnets participating via vpn.

Enable bi directional match in vpn settings in global properties and set vpn column in the rule with 3 things:

vpn community -> internal

internal -> vpn community

vpn community -> vpn community

Install policy -> test

I really have high confidence this would work.

Re: Understanding a kernel vpn debug

ibrown — Thu, 29 Jan 2026 09:45:05 GMT

Thank you. Disappointingly, my vpn debug created iked0.elg and iked1.elg, but no legacy*.elg or xmll files, which is annoying as ikeview won't handle those. sk30994 says it should but it didn't. Perhaps it's a nuance on my R81.20 cluster.

Re: Understanding a kernel vpn debug

Vincent_Bacher — Thu, 29 Jan 2026 09:58:14 GMT

It’s been a while since I last used vpn debug and viewed it using ikeview, but as far as I remember, vpn debug generates XML output for IKEv2 and ELG output for IKEv1. Is this an IKEv2 tunnel ?

Re: Understanding a kernel vpn debug

AttiqRahman786 — Thu, 29 Jan 2026 10:10:19 GMT

Have you tried disabling the VPN accel? I remember once I had to do that for a specific peer in a one way traffic situation. remember it is a global change so only specify the peers you want to disable vpn accel.
Clish Command - VPN accel off

Re: Understanding a kernel vpn debug

ibrown — Thu, 29 Jan 2026 10:41:48 GMT

Thank you. I don't have NAT disabled in the community as I am having to hide my internal subnets to access the 3rd party.

It has had permanent tunnels set but it made no difference. It is set as one tunnel per pair of hosts, but the enc domain is my nat address (single host) and two hosts at the third party, and they are accessed as active/standby so we are only seeing a phase 2 sa for a pair of hosts.

Re: Understanding a kernel vpn debug

ibrown — Thu, 29 Jan 2026 10:49:41 GMT

Yes IKEv2, I don't understand why no xml debug occurred given i cut and pasted the instructions from the SK, but it did not. Just the two elg files.
I'll try generating it again

Re: Understanding a kernel vpn debug

ibrown — Thu, 29 Jan 2026 10:51:49 GMT

Thanks, I'll check with the 3rd party on the enc domain. I am loathe to enable a global property that might affect the other VPNs already running, at this moment, it is off at the moment.

Re: Understanding a kernel vpn debug

ibrown — Thu, 29 Jan 2026 10:54:49 GMT

Yes, I see a traffic selector error, where my cluster fires back every address it knows including other vpn target addresses. I've spoken to tac about that behaviour but it appears 'by design' but I don't like it...!

Re: Understanding a kernel vpn debug

ibrown — Thu, 29 Jan 2026 10:56:47 GMT

Thanks, I am going to try to generate it again, just have to wait for the 8 hour timeout. Using the SK didn't generate anything ikeview would work on.

Re: Understanding a kernel vpn debug

Vincent_Bacher — Thu, 29 Jan 2026 11:24:05 GMT

Strange. Maybe you could try using

vpn debug trunc ALL=5

edit: and I would suggest to do

vpn accel off <peer_IP>

before debugging as already stated here

and turning on afterwards

Re: Understanding a kernel vpn debug

the_rock — Thu, 29 Jan 2026 12:11:13 GMT

It would not affect anything, as it just lets you modify that setting in the rule column, which might not even fix the issue, just something Im used to doing for route based tunnels. I would still try empty group as enc domains, you dont need other side to do anything with that. You just change it for both on CP side. I will send you screenshot later to demonstrate what I meant.