GAiA Shows "Site cant be reached" - Logs show its allowed

[SecurityNed]

Hello Checkmates!

I'm in an unusual dilemma right now.

I, for some reason, can't access the GAiA portal on one of my NGFWs. I can after performing a fw unloadlocal command.

The thing is I have checked already the following:

1. defined a unique port in the portal - i have defined it this way, as leaving it blank would automatically route me to the web VPN portal

2. checked logs for any blocked traffic - there's no blocked traffic as per logs 

but still, i cant access the GAiA portal, only after i performed a fw unloadlocal

Is there any other thing that I can check to confirm if there's anything thats preventing me to access this portal? A NGFW on the same segment (172.16.16.254) works as intended, only this newly added one is experiencing this issue.

Hoping for your insight on this one Checkmates!

Edit: Here's the policy: I changed already the 4443 to 8844 as there was a policy that used the 4443 port. This is to avoid confusion.

 

[AkosBakos]

Hi @SecurityNed 

Have you tried the followings:

• a simple reboot one of the afffected GWs
  • both member are affected?
• Change the port to an  another unique port
• What does the show web ssl-port command show for port?
• what does the  fw ctl zdebug + drop show?

Cheers

Akos

[SecurityNed]

Hello @AkosBakos,

I've already:

• rebooted the affected GWs (only one is affected, the other one works)
• While waiting for a response I've changed 8844 to 4334, same behavior
• I haven't checked this command yet
• This one as well, as I've only used zdebug for traffic-related stuff

I'll get back to you when I get results for this. Currently due to time restrictions we're performing changes under fw unloadlocal.

[AkosBakos]

Hi @SecurityNed 

You are correct fw cl zdebug..... I wanted to write this, but i am a human 🙂

One more  thing, can we say that, only the standby member is affected always?

To be 100% percent sure, you are tring to access the MGMT IPS, right?

And there was an issue, take a look at on this: https://support.checkpoint.com/results/sk/sk147493

Cheers

Ak

[SecurityNed]

Hello @AkosBakos ,

Not yet, currently both are standalone NGFWs, and thus we're wanting everything to be ready before we proceed with the cluster activity,

I'm accessing it both via MGMT IP and via the configured IP where it is reachable on the Smart1 Appliance

[AkosBakos]

Hi @SecurityNed 

Aha, so it seems Policy issue for me, because #fw unloadlocal solves the problem. 

I think you don't have a large policy, and this gW are not productives, so maybe yo can clone the working policy, and push it to the not working gw. 

Of course, do the necessary changes before installation. If it solves the problem -> this is a policy issue.

If I misunderstood that, and they are productive GW-s plese forget the above.

Akos

[SecurityNed]

Hello @AkosBakos ,

Actually they're running on the same policy table when publishing. So they're using the same policies with the working FW. I might try configuring a separate policy table for the meantime while we configure it to HA.

Will update you once there are unusual stuff after our test.

[the_rock]

Can you send this please?

clish -> show web ssl-port

Andy

[Lesley]

This SK is the way to go. https://support.checkpoint.com/results/sk/sk91380

Please follow it. Explains about fw ctl zdebug and tcpdump 

We need to know why traffic is being blocked. Could be anti-spoofing for example. 

Maybe try to filter on IP and not port. So only 10.1.1.1 (example) and not src:10.1.1.1 or dst:10.1.1.1

[_Val_]

@Lesley you did not specify any SK, or am I blind?

[Lesley]

Thanks edited my post