One of those facepalm moments this morning. I have been troubleshooting an issue where my network monitoring station has been unable to ping the standby firewall interface via a VPN tunnel terminated on the remote firewall HA pair.
Upon reviewing in SmartView Tracker, I could see the incoming ICMP echo request being dropped by the standby firewall with the complaint, “Clear-text packet should be encrypted.” In my mind, I’m thinking that the ICMP echo request WAS encrypted. There’s no other way the packet could have gotten there except through the IPSEC tunnel. And that’s true…but the issue here is that the IPSEC tunnel is being terminated on an active/standby firewall HA pair. Only the active firewall is encrypting and decrypting IPSEC traffic. So in this case, my NMS would fire off a ping destined for the standby firewall, the packet would go through the IPSEC tunnel and be decrypted by the active firewall, and then forwarded unencrypted to the standby firewall. The standby firewall would look at the unencrypted packet, notice that he had a VPN configuration indicating that this should have been an encrypted packet, gets upset, and drops the packet.
According to CheckPoint, this is the way it’s supposed to work. Solution article sk34080 states, “This is is an expected behavior. Connections to the Standby cluster members are not supported in HA clusters. Even if the Standby cluster member could accept the packet, the reply from the Stendby member would be routed via its external interface. That means, it would be encrypted by the Standby member using active member’s SPI and counter – thus disrupting the VPN tunnel.”
And thus my facepalm. As soon as I read that, I had that moment of insight – how else did I think it was supposed to work?