No ICMP traffic trough VPN after migration

[JacWev]

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

1. [5600 B] Poweroff the R81.20 the standby cluster member (5600 B)
2. [9100 B] Connect to R81.20 new member and configure interfaces and routes,... with the same settings from the old [5600 B].
3. 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, 

[PhoneBoy]

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?

[JacWev]

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.

[PhoneBoy]

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

[Timothy_Hall · Accepted solution]

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.

[JacWev]

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

[Timothy_Hall]

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.