Invalid checksum TCP drops between HA MGMT Servers + members?

[dphonovation]

I have a cluster with 2 MGMT servers (Active and Standby). I'm getting a ton of these: 

CP_redundant on the way from Active to Standby

CPD_Amon: From Standby to a managed node:

Otherwise, the cluster is green. I can push policy fine. HA MGMT is sync'ing, etc. I do see some flows allowed in the midst of all the drops for the same port, so perhaps that explain the green cluster.

I'd still like to know what these drops are for?


Network is:

{10.10.171.0/24} --> 10.10.171.1 eth2-[CPSite1]-eth4 172.30.0.1/28 <----> 172.30.0.4/28 eth4-[CPSite2]- --> {10.20.171.0/24} 

There is a route on Checkpoint 1: 10.20.171.0/24 via 172.30.0.4

There is a route on Checkpoint 2: 10.10.171.0/24 via 172.30.0.1

[Chris_Atkinson]

Have you reviewed sk172266, perhaps suggests some underlying network issue?

The "window" for this can be increased in consultation with TAC to negate if the underlying cause cannot be eliminated.

[dphonovation]

I'll give a capture a go. I just noticed some of the same coming in from RemoteAccess VPN Clients, from WAN to LANs directly behind the checkpoint. Nothing crazy. And same thing, there is an allow right beforehand and the traffic works!

[dphonovation]

Here's a cap of the problem:

10.10.171.12 (LAN) hitting https://10.20.171.4 (LAN on other side of S2S tunnel)

I wonder if this could be a VMWare/ESX TCP Offload gotcha.

[dphonovation]

Bingo!

I changed the adapter for ONLY my WAN interface on the CP to E1000 from VMXNET3 and these stopped.

I'm on an old many gens ago Dell server. Running broadcom (bnx3) drivers and ESXi 6.5 with latest approved VIB. (No support for 6.7 or 7) if any one is in the same situation.