Understanding a kernel vpn debug

[ibrown]

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

[Vincent_Bacher]

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

[ibrown]

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

[Vincent_Bacher]

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.

[ibrown]

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.

[Vincent_Bacher]

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 ?

[ibrown]

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

[Vincent_Bacher]

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

[israelfds95]

If you are using IKEv2, you need to check the IKEv2 log files, not the IKEv1 ones. That’s why no information was shown. The IKEv2 log files include ikev2.xml, iked0.ikev2trace, or any files matching ikev2*.

To view them in IKEView, you need to open the Windows file browser and set it to show All files or specifically filter for IKEv2 files. Then you will be able to see and analyze the collected IKEv2 logs

review the https://support.checkpoint.com/results/sk/sk30994 of ikeview

[ibrown]

Sadly when I do a vpn debug, no ikev2.xml file is ever created. I'll try to capture a new ikev2trace when the timer expires again , be tomorrow now. And see what it contains. Thanks

[AttiqRahman786]

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

[the_rock]

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

[ibrown]

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.

[the_rock]

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.

[ibrown]

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.

[the_rock]

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.

[the_rock]

This is what I meant.

You do the same for interoperable object.

 

[AttiqRahman786]

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.

[israelfds95]

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

1. Collect VPN Debugs:
   
   https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SitetoSiteVPN_AdminGuide/Con...

   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

2. Analyze with IKEView - sk30994:

   • Download IKEView (see: What is the IKEView utility?)
   • Use it to analyze the debug files for detailed IKE negotiation information.

3. 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

4. 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,

[Tal_Paz-Fridman]

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

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

[ibrown]

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.

[CaseyB]

Do you see any logs using:

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

[ibrown]

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...!

[israelfds95]

At the moment, we don’t have enough information to provide proper assistance. IPsec site-to-site VPN involves many elements, and only with full visibility of all relevant configurations (on both sides) and debugs, can we accurately diagnose the issue. Otherwise, we are just guessing possible causes.

**To help you further, please provide:** - Details about your VPN community configuration (Star/Mesh, participating gateways, VPN domains) - Link Selection settings and whether ISP Redundancy is enabled - Relevant logs (e.g., `vpn debug`, `ikev2.xmll, iked0.ikev2trace (look on ikeview all files)`, SmartView Tracker logs) - Topology screenshots or configuration snippets

How you configure the VPN domain's on both side? 

**Technical Suggestion:**

If your community is configured as Star with only this remote peer and no other satellites, try changing Tunnel Management to “One VPN tunnel per Gateway pair.” This will make Phase 2 on the Check Point side use a full VPN domain (0.0.0.0/0.0.0.0), simplifing the phase 2. Then push the policy and check if the tunnel establishes in Phase 1 and Phase 2. You can verify using: vpn tu tlist -p <remotepeerpublicIP>

Take a look on this video too: 
Cisco to Check Point firewall VPN: A Complete IKEv2 Setup Guide
https://www.youtube.com/watch?v=2VzYSTgNTFQ

For now, this is all I can do for you. I suggest opening a TAC case.

Best Regards

[CaseyB]

It sounds like you just have a mismatch of the hosts/networks being used in the Phase 2 proposal.

• Which tunnel sharing mode are you using under "Tunnel Management"?
• Both devices need to match / agree on the hosts/networks being exchanged and they need to use the same /CIDR

I find it helpful to use granular encryption domains for all VPN tunnels, so I know Check Point is using the right /CIDR of a subnet in a tunnel. If you are just exchanging a couple subnets, you would use something like this:

• Tunnel Sharing Mode: One VPN tunnel per subnet pair
• Create a new simple network group containing the subnets you want to exchange.
• Apply the group to the community.

[ibrown]

I am set for one sa per pair of hosts. I am waiting on the third party to tell me what their enc domain is expecting before i tighten up the enc domain in the community. Thanks. Out of curiosity, if I use a NATd address as my enc domain, would the vpn community enc domain be just the nat address or both the source AND the nat address ? Or just the source ?

[the_rock]

I have a gut feeling changing it to per gateway might make a difference, cause we do that for ANY route based vpn, regardless whats in the enc domain. And, FWIW, all of them do WORK fine.

[Vincent_Bacher]

Same here. 

Back in the day, when I was regularly dealing with VPN issues and struggling with Phase 2 problems, I’d simply check if I could set the VPN domain on the Check Point side to “Tunnel by Gateway” and, on the other side, configure Phase 2 with 0.0.0.0. Once I got the confirmation that I was allowed to do that, everything was fine. And even though it’s a bit of a compromise, it still got the job done.

[the_rock]

Here is what I find works.

If its route based tunnel, specially with cloud providers, I ALWAYS set end domains for both sides as empty group (actual subnet for vpn domain for the cp object in smart console can be something else), as long as its empty group for community side, same for interoperable object, set it as permanent, set pert gateway pair, ike v2,aes 256, sha 256, dh group 20, never an issue. That works for both AWS and Azure.

[Vincent_Bacher]

Empty group is an interesting option.