GUI client unable to access R80.10 management server behind firewall

[Tarmo_Koponen]

Hi,

I'm hoping someone could offer help how to solve a problem with having trying to access an R80.10 management server's private address behind R80.10 firewall with GUI client and failing. The setup is in Azure but I don't think that's the problem here since you can login via SSH to the server and HTTPS to the GAiA via same address.

GUI client -----> FW<----VPN---> R80.10 FW ----> R80.10 Mgmt Server

Checking the logs the packet from GUI client are logged in implied rule level and passing through the firewalls, and with fw monitor you can see the packets passing the R80.10 firewall and return packets from the management server truing to head back to the client, but the return packets get dropped because they are not SYN packets. It seems that there isn't any session associated with that initial passed packet and thus the return packets get dropped?

When checking the implied access control connection rules settings the only option is to disable them, you can't change order from the "First" to anything else.

Any idea how to allow access for GUI clients to the internal address with out disabling the implied rules and recreating them by hand?

[Alejandro_Mont1]

You stated you are able to access both ssh and the webui from the same client PC, correct? Are both of the firewalls managed by the same management server you are trying to authenticate to? Lastly, "FW" firewall-is it on R77x or R80x?

[Reinhard_Stich]

please check if the 19009 GUI communications is going into the VPN tunnel - of if the firewall tries to send it outside the VPN ...

[PhoneBoy]

The ports that matter here (TCP) are: 443, 19009, 18190 (for R80.x)

[Don_Paterson]

Hi Dameon,

Jumping into a thread here but its about port 18190 (CPMI) and the reason for it being in use when no legacy SmartConsole GUIs are open?

Why is that?

I wondered if it was to have an already established channel/connection to launch the older GUIs in, since they kind of piggy back off the existing SmartConsole (R80.x) 

C:\Users\user>netstat -na | find "18190"
TCP 192.168.123.134:55503 18.195.203.96:18190 ESTABLISHED

Regards,

Don

[PhoneBoy]

Objects that still use legacy APIs (e.g. gateway objects) will still need to be modified through CPMI, even if no legacy SmartConsole is open.

This is why you see connections on both 19009 and 18190.

[Don_Paterson]

Thanks. I have doubt about the legacy APIs part... Is it that in the case that the SmartConsole (R80.x) is talking to fwm on 18190 (talking CPMI) but only for objects that have older versions reflected in the properties?

If there were for example only R80.x version objects in a new deployment could I assume there would be no traffic on port 18190 unless for example SmartUpdate was opened up and in use?

[PhoneBoy]

Gateway objects are only one example, there are several others that use CPMI as well.

I would expect to see traffic on both ports.

[Tarmo_Koponen]

Hi,

yes, the SSH and HTTPS are successful from the same client with internal private IP address behind the VPN.

No the FW in "on-premise" is R77.30 and its management server is not managing the R80.10 FW in cloud, the R80.10 management server in the cloud is doing it.

The logs show this:

Interface Direction:    inbound
Interface Name:         eth0
Id Generated By Indexer:false
First:                  true
Sequencenum:            1
Source Zone:            External
Destination Zone:       Internal
Service ID:             CPM
Source:                 172.x.x.x
Source Port:            52767
Destination:            10.x.x.x

Destination Port:       19009
IP Protocol:            6
Action:                 Accept
Type:                   Connection
Policy Name:            Standard
Policy Management:      xxxxxxx
Db Tag:                 {4F615F84-6027-1843-8B48-A76C287B475A}
Policy Date:            2018-05-18T09:26:40Z
Blade:                  Firewall
Origin:                 xxxxxxx
Service:                TCP/19009
Product Family:         Access
Logid:                  0
Access Rule Name:       Implied Rule
Access Rule Number:     0
Rule UID:               0E3B6801-8AB0-4b1e-A317-8BE33055FB43
Layer Name:             Network
Interface:              eth0
Description:            CPM Traffic Accepted from 172.x.x.x to 10.x.x.x

and as I mentioned in the fw monitor the return packets from cloud management server are trying to head back to the GUI client but are dropped because "First packet isn't SYN".

[Alejandro_Mont1]

Since the R77x gateway is not managed by the server we are trying to access try creating an explicit rule allowing traffic on the ports listed above-443, 18190 and 19009.

[Houssameddine_1 · Accepted solution]

This is a traditional issue. "Guys you need to know that any traffic matches implied rules will never get encrypted". You might need to disable the implied rules for the following service 18190 CPMI, 19009 CMP, TCP 18264 CRL fetch. (The following SK will show you how to do it for CPMI 18190 and do the same thing for CPM and CRL fetch but you need explicit rules, based on the description you have 2 management servers and the change should be done on both because the change should be pushed to both firewalls R77.30, R80.10, on the R77.30 management server you will not find the CPM service 19009) I don't recommend doing it this way because It will be global change (I believe the best solution is to  have a jumpbox in Azure cloud and use RDP after that access the management server )

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...