DAIP gateways with "Not available" or "Lost" status on SMS

[William_Gutierr]

Hello folks!

In a scenario with a SMS who manages external DAIP gateways, it's very common to not have their status being correctly showed into SmartConsole "Gateways&Servers" tab.

Some gateways we receive "Lost" status, others just a "Not available". On this scenario, we have a SMS on R81.20, take 10. The external managed gateways are SMB's, 1500 family... some in R80.20, last build available, others already into R81.10, last build available until the day of this post.

We have vpn lan2lan with these remote gateways, and surely we can monitor with other monitoring system, like zabbix, whatever. But into my SmartConsole, don't you think we should have a smarter way to check it?

I'm able to prepare policy normally (since the gateway is DAIP, it will fetch policy according to automatic checks every 240 minutes, by default, and I'm very aware that we can change this value, but 240 minutes is ok, no problem with that... if I'm in a rush,I connect into specific SMB and push policy manually), manage the remote gateways via Reach My Device, there is no problem with SIC communication (including logs are sent normally to my SMS).

My questions are: is that a normal statement for you guys? Do you have a tricky way, a sk to fix this, or a "secret" procedure to solve this status? Or you all just think "nehh it's a cosmetical issue, i really don't care with this status".

I think we should have a better way to monitor it on SmartConsole, things like the external gateway send some "keep alive" or something like a Real Status, independend of being a DAIP one. I mean, comeon, we are on 2023, there is a lot of development envolved on it, and Check Point is very big to not care about how their systems are monitored.

[G_W_Albrecht]

I had such issues, too, but in Lab - other devices were filtering the traffic between SMBs and SMS, so Dashboard & Policy install had errors as in your case. Changing the GWs network resolved it.

I would involve TAC as i do not think the reason for your issue is the same !

[Garrett_DirSec]

Hello -- as a general rule, I've always felt that DAIP gateways "need more tools" to insure their reliable operation.  

As it stands, if your remote device frequently changes WAN IP, the DAIP function is as frustrating at minimum -- and kraco and "throw it out the window" at worst.

I have various 1500 devices configured as DAIP objects and they are frequently moved around depending on their use.    They are used for ELECTIONS and necessarily placed behind home office consumer routers when in operation.   The DAIP mechanism is not reliable and source on constant frustration, poking, and prodding.

The customer wants to throw thirty-odd 1500-series boxes in trash and buy Cradlepoint because they know that works (and it does).  

To make matters worse, add Smart1-Cloud to the mix (managment-as-a-service) and you get the distinct impression that no-one in R&D and product mgmt has ever tested this combination of mechanisms in any way-shape-or-form. 

It's basically unusable.    DAIP doesn't update in predictable manner and MaaS tunnel never recovers in predictable way.   Neither have good command-line resources to change/debug/poke/configure their behavior.

In our case, device is configured at central location and then placed in new location.   the placement is done by non-technical person and it's ridiculous to expect high-tech command-line person to be at Church in rural America because the MaaS+DAIP combination is not fully vetted and tested by vendor. 

CP sales will tell everyone it works all day long.    CP TAC will get engaged and get SME on line (after various escalations).   Ultimately, we get to point where it's obvious that operational requirements are indeed different for what is being QA'ed. 

Thus, the development and functional requirements using by CP R&D are different what what we need and expect.     However, we never get to point where someone states "that will never work", but we never get solid and reliable solution where it DOES work.

Per comments in original post, the addition of some very basic config options and real-time tools could solve 80% of the problem.    Tools and Logic on gateway to help insure MaaS tunnel resumes.    Tools and config options to help DAIP be more a) predictable, and (b) reliable when updating SMS service.    

The fact these small tools and tweaks not available reflects simply how often QA and R&D actually using and testing these boxes (ie. not much).

[William_Gutierr]

Just to the records: I created a SR#6-0003839228

Unfortunatelly, there is no solution, is a limitation listed on  sk178604, ID SMBGWY-2525.

TAC suggested me to create a RFE, so I did it, but there is no deadline to be solved or improved:

RFE ID: Y5868q5CG

[the_rock]

Thanks for the update. So, there is no any workaround at the moment for this?

Best,

Andy

[Garrett_DirSec]

Hello -- we have open case asking for more information on configuration options for "update interval" for DAIP service on SMartCenter.   

Reference #3 on DAIP FAQ  ("configurable").       https://support.checkpoint.com/results/sk/sk167473

The initial lower tier response was "specify a shorter FETCH interval" on the gateway.     This wasn't the answer we were looking for (or maybe an answer to a different question), but it may help here. 

I'm fairly certain this "fetch" option in SmartConsole is only present for SMB device (embedded GAIA). 

[the_rock]

Makes sense to me.