topic Re: Can't monitor secondary node over IPSec tunnel in Firewall and Security Management

Can't monitor secondary node over IPSec tunnel

Johannes_Schoen — Thu, 21 Feb 2019 08:57:11 GMT

Dear Community,

as an ISP we are monitoring our customer environments throug IPSec tunnels from our datacenter.

I don't know why, but two of our Check Point installations are strange - I cannot access the secondary node through IPSec - other sites work well with the same design. One troublemaker runs an old VRRP cluster (R77.30), the other on is a clusterXL (R80.20).

This is the general setup:

The montoring server is able to contact the MGMT VIP and node one, but obviously we need to monitor the second node as well.

The kernel param "fwha_forw_packet_to_not_active" is set to yes on both nodes, but packets are getting dropped as "received unencrypted packet...should be encrypted". I also tried to do a hide nat with a dummy ip to masquerade the access to the second node, as if it is sourced from that dummy ip - didn't work either.

I can't find the point I'm missing here - hopefully the community can help?

Best Regards

Johannes

Re: Can't monitor secondary node over IPSec tunnel

Maarten_Sjouw — Thu, 21 Feb 2019 09:15:49 GMT

For VRRP there are 2 settings in the dash, on the cluster object, forward to cluster member and hide behind cluster IP:

Turn them both off and these type of issues are no longer happening.

For the clusterXL double check that the correct member is dropping the traffic.

Re: Can't monitor secondary node over IPSec tunnel

Johannes_Schoen — Thu, 21 Feb 2019 09:43:28 GMT

Dear Maarten,

many thanks for your response, I wasn't aware of that VRRP setting.

But unfortunately that doesn't work, I still got this error (on the second node):

Re: Can't monitor secondary node over IPSec tunnel

Maarten_Sjouw — Thu, 21 Feb 2019 09:48:58 GMT

Then you still have a problem with either that community (maybe a excluded service) or the VPN topology is not correct.

Re: Can't monitor secondary node over IPSec tunnel

Johannes_Schoen — Thu, 21 Feb 2019 10:09:44 GMT

Doublechecked that.

VPN domain monitoring site: <monitoring-dmz-net>

VPN domain production site <management-net)

No natting between both of them

No excluded service in the domain.

The strange thing is, that we have working sites with the same configuration, so I'm wondering why that "unencrypted received...expected encrypted" occurs

Re: Can't monitor secondary node over IPSec tunnel

G_W_Albrecht — Thu, 21 Feb 2019 10:45:51 GMT

This shows that the ping is not sent thru VPN tunnel...

Re: Can't monitor secondary node over IPSec tunnel

Johannes_Schoen — Thu, 21 Feb 2019 11:22:08 GMT

I can see on the interoperable ipsec device that the monitoring traffic for the primary and secondary node is sent to the tunnel.

Communication to primary node is working well, so I guess that is no routing issue.

I think the primary Checkpoint terminates the IPSec tunnel, removes the encryption (as expected) and sends the data to the secondary node with the nearest interface (in this case management interface). Somehow the secondary node expects the traffic to be encrypted anyway.

Or do you mean I need two vpn tunnels against the Checkpoints? (it's possible due to that "we-need-3-public-ips-even-if-we-use-only-one-thing")

Re: Can't monitor secondary node over IPSec tunnel

Maarten_Sjouw — Thu, 21 Feb 2019 11:48:01 GMT

There is no way to do this indeed, as you say the traffic is decrypted on the active node and forwarded to the backup, and dropped there because it is cleartext.

You cannot build separate tunnels to the different members.

Re: Can't monitor secondary node over IPSec tunnel

G_W_Albrecht — Thu, 21 Feb 2019 12:17:17 GMT

Maybe the workaround from sk106425 can help ?

Re: Can't monitor secondary node over IPSec tunnel

Johannes_Schoen — Thu, 21 Feb 2019 12:18:06 GMT

So it's not possible to monitor two hardware node through an ipsec tunnel with Check Point?!

Re: Can't monitor secondary node over IPSec tunnel

Maarten_Sjouw — Thu, 21 Feb 2019 12:24:13 GMT

Not if they are in a cluster and the tunnel terminates on the cluster. Been there.

Re: Can't monitor secondary node over IPSec tunnel

Johannes_Schoen — Thu, 21 Feb 2019 12:27:46 GMT

Thanks for the suggestion, but the sk describes drops due to address spoofing, I think I have a different problem here

Re: Can't monitor secondary node over IPSec tunnel

Maarten_Sjouw — Thu, 21 Feb 2019 12:29:36 GMT

The spoofing error is due to the fact that the traffic comes from the other member, as I said before, look at the incoming interface the traffic is being dropped upon.

Re: Can't monitor secondary node over IPSec tunnel

Johannes_Schoen — Thu, 21 Feb 2019 12:47:31 GMT

To be honest, I don't understand what you mean/referring to.

The incoming interface for the monitoring traffic on the second node (which drops that traffic) is the management-interface with ip <mgmt-subnet>.3. Topology is defined as per ip and subnet and anti-spoofing is set to detect for that interface.

The firewall detects address spoofing, but the drop reason is due to the screenshot above.

If you really cannot monitor the hardware through vpn, we cannot recommend checkpoint products for any customer.

I don't know any other relevant firewall vendor where that issue is expected behavior (without setting options which will decrease the security) - please correct me if I'm wrong

Re: Can't monitor secondary node over IPSec tunnel

G_W_Albrecht — Thu, 21 Feb 2019 13:15:22 GMT

Why not open a ticket with TAC ? Maybe here we have different # fw ctl get int fw_allow_simultaneous_ping settings, or just different routing ! Monitoring of hardware mostly uses SNMP, not ICMP...

Re: Can't monitor secondary node over IPSec tunnel

Johannes_Schoen — Thu, 21 Feb 2019 13:20:15 GMT

Yeah, I guess that is the next step.

It's the same when using snmp, but a continous ping from commandline is not that distracting for our colleagues, than having our monitoring system sending snmp requests, which result in an error state.

Re: Can't monitor secondary node over IPSec tunnel

Maarten_Sjouw — Thu, 21 Feb 2019 19:09:00 GMT

What I mean by the interface is that when the traffic comes through the VPN tunnel to FW1 to go to FW2, it will be sent from FW1 to FW2 over a specific interface, so when you look at the details of the log entry, what is the interface you see the traffic come in on FW2 where it is being dropped, therefore the spoofing could because it is coming in over an interface where this traffic should not be entering normally.

Lets say you use the eth6 interface for monitoring and the inteface that the VPN terminates on is eth1, you do not have the monitoring system as a network you would expect to enter on eth6, you expect that to enter on eth1, butr as fw1 decrypts the traffic and forwards it to fw2 eth6 this would not accept this traffic there and drop it on spoofing.

Re: Can't monitor secondary node over IPSec tunnel

Koby_Kagan — Thu, 21 Feb 2019 19:43:48 GMT

Hi Johannes,

I know there is was an issue with "fwha_forw_packet_to_not_active" in R80.20.

A hotfix was released today on top Jumbo Take 43.

I suggest to open a ticket to TAC and request this Hotfix:

In the description mention that you have R80.20 and fwha_forw_packet_to_not_active is not working as before, and request this Hotfix R80_20_t43_jhf_218_main.

I suspect it will solve your issue.

Thanks,

Koby

Re: Can't monitor secondary node over IPSec tunnel

Norbert_Bohusch — Thu, 21 Feb 2019 20:31:40 GMT

Cool, we also encountered issues with this kernel parameter not working at some customer with R80.20.

Re: Can't monitor secondary node over IPSec tunnel

Koby_Kagan — Thu, 21 Feb 2019 20:43:06 GMT

sk147493