Why are DAIP gateways never really shown as connected ... even when they working just fine?

[Thomas_Eichelbu]

Hello CheckMates,


this is an issue which causes alot of questions by customers and by me too...
DAIP gatways are never shown in SmartConsole as conencted (green) but as disconnected (red)?
Since the first three appliances in the picture are really online (red) its annoying to see them as disconnected ...

Is there a good explanation, and how to fix this?

In Dashboard they are listed with IP´s like 0.0.0.X and incrementing ... 
Every one of this appliances has of course internal unique IP adresses .. .is there are way to play with them and do some creepy NAT?
I think i have seen an article on CheckMates how to overcome this, but i cannot find it anymore ...

Any help or ideas are welcome!

best regards
Thomas

[G_W_Albrecht]

This looks very unnatural - i would suggest to contact TAC to resolve it !

[Us4r]

Hello Thomas,

the Management Node needs to establish a connection to the DAIP Gateways. If this is not working because no NAT - Rules exist on the provider router for the SMB - Appliance, then you get the unreachable symbol presented.

[G_W_Albrecht]

In most cases, SMS is NATed behind a GW - see sk66381: How to configure Management behind NAT in Security Gateway 80 / 1100 / 1400 Appliance setup for help !

[Thomas_Eichelbu]

Hello. well no, the SMS works perfect for other gateways with public IP ... just the DAIP IP GW´s are not shown as connected (green) but as disconnected (red)
The SMS hsa of course all this settings from SK66281 

for example the VPN certificate says:


Subject: CN=XXXXXXXXXXXXXXXXXXXXXXXXX
Issuer: O=XXXXXXXXXXXXXXXXXXXX
Not Valid Before: Sun Oct 21 14:20:21 2018 Local Time
Not Valid After: Sat Oct 21 14:20:21 2023 Local Time
Serial No.: 75149
Public Key: RSA (2048 bits)
Signature: RSA with SHA256
Subject Alternate Names:

----> LOOK HERE  Address: 0.0.0.2

CRL distribution points:
http://XXXXXXXXXXXXXXX:18264/ICA_CRL1.crl
CN=ICA_CRL1,O=XXXXXXXXXXXXXXXXX..bn78tq
Key Usage:
digitalSignature
keyEncipherment
Basic Constraint:
not CA
MD5 Fingerprint:
95:D1:57:3E:04:08:94:58:55:6E:CF:14:CC:58:A3:EA
SHA-1 Fingerprints:
1. 99:99:07:6C:7D:1C:10:8C:B8:A2:88:7F:5E:CB:0E:28:34:27:F0:A5
2. HOLE OMAN SHOW WERE MUTT WOW MATH FLO JAW MOLD LOAF FLY

so the DAIP GW´s get dummy IP´s starting at 0.0.0.1 ... here this guy has 0.0.0.2 ...

the MGMT will never reach a 0.0.0.2 adress ... 

best regards
Thomas.

[Us4r]

Hello Thomas,

<<so the DAIP GW´s get dummy IP´s starting at 0.0.0.1 ... here this guy has 0.0.0.2 ...

the MGMT will never reach a 0.0.0.2 adress ... >>

The mentioned 0.0.0.x - Addresses are only as you mentioned internal "dummy" IPs. They can be used for filtering, when you don't know the exact OIP.

But as I mentioned, check if a NAT / DMZ-Host Configuration is there on your provider router for the checkpoint appliance.

You need this, otherwise Management Node can never connect to the correct OIP.

[Nik_Bloemers]

This annoys me too 🙂

I wish Check Point would add a status 'push' CPD AMON mechanism for DAIP gateways, so they can report to the SMS instead of the SMS only being able to pull status.