topic Re: No ICMP traffic trough VPN after migration in Firewall and Security Management

No ICMP traffic trough VPN after migration

JacWev — Tue, 21 Jan 2025 08:19:39 GMT

Dear CheckMates,

We encounter some strange behavior after the migration of our checkpoint cluster.

We changed the hardware from Check Point 5600 to Check Point Quantum Force 9100 appliances.

The steps we have taken for a successful full migration are:

Current state -> A is active, and B is stand-by

[5600 B] Poweroff the R81.20 the standby cluster member (5600 B)
[9100 B] Connect to R81.20 new member and configure interfaces and routes,... with the same settings from the old [5600 B].
Install SIC, add license, change cluster version, fix cluster member topology, install policy on gateway [9100 B] (remove flag "if fails")

[5600 A] remains active

4. [5600 A] Poweroff the R81.20 appliance (5600

5. The [9100 B] become active

6. [9100 A] Connect to R81.20 new second member and configure interfaces and routes, with the same settings as the old [5600 A]

7. Install SIC, add license, fix cluster member topology, install policy on both new gateways (add flag "if fails")

After the successful migration we encounter that there is no ping traffic through the VPN Tunnels of the VPN Community. The VPN Community are branch offices with Check Point devices.

We pushed to all the Check Point the correct policy set.

So, after some digging, we see that the ICMP traffic is routed through the VPN tunnel but not receiving on the other side. Other Protocols such as SSH or https are working fine but no ICMP.

The old cluster is running on R81.20 JHF take 86 the new cluster is running on R81.20 JHF take 92.

That’s the only difference between the cluster’s devices. due to a short migration we could not update the devices to take 96.

So have some one any ideas ?!

Thanks for helping,

Re: No ICMP traffic trough VPN after migration

PhoneBoy — Tue, 21 Jan 2025 15:47:18 GMT

Curious how you validated the ICMP is going through the tunnel.
Did you use a tcpdump/fw monitor to see if the ICMP traffic left the remote gateway?

Re: No ICMP traffic trough VPN after migration

JacWev — Sun, 26 Jan 2025 13:56:52 GMT

Hi Phoneboy,

Today we had a remote session with TAC. We see traffic is entering the tunnel received bij the other and return traffic is not send.

When we change the VPN community settings and we pushed a policy the gateway is rebooting.

Strange behavior, Check Point is investigating the problem.

Re: No ICMP traffic trough VPN after migration

PhoneBoy — Mon, 27 Jan 2025 20:41:30 GMT

So the remote gateway isn't sending the return traffic?
Hopefully TAC can assist you in getting to the bottom of it.

Re: No ICMP traffic trough VPN after migration

Timothy_Hall — Mon, 27 Jan 2025 21:08:54 GMT

ICMP traffic is always supposed to go slowpath with no acceleration, however the 9100 appliance is a Quantum Force appliance and will have UPPAK enabled by default. You may want to try disabling UPPAK to see what happens, as I've seen some strange VPN behavior with UPPAK at a customer's site. This was for IPSec traffic transiting the gateway (but not terminating on it) but that was supposed to go slowpath too: sk182775: Packet loss (fwconn_key_init_links failed) for ESP packets when using User-Mode SecureXL.

This was fixed in Take 90 (which you have), but you may have a slightly different issue. Another step would be to disable all acceleration for that tunnel with vpn accel off (VPN Peer IP) although I doubt that will have any effect on the issue.

Re: No ICMP traffic trough VPN after migration

JacWev — Sun, 09 Feb 2025 12:41:28 GMT

Hi Timothy,

When we switch to kernel settings the problem is gone. With cpconfig -> SecureXL -> kernel mode. We changed is on both FW's in the the cluster. Now we are able to ping trough te VPN. Thanks for pointing this out.

Kind Regard,

Jaco Wevers

Re: No ICMP traffic trough VPN after migration

Timothy_Hall — Sun, 09 Feb 2025 14:01:52 GMT

Glad to hear that helped. However any time you have to disable SecureXL partially, or switch from the default UPPAK mode back to KPPAK mode (assuming it is not a known limitation of UPPAK), that situation is a bug that should be reported to TAC. I'll be talking about UPPAK extensively in my CPX Vegas speech.