Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
SecurityNed
Collaborator
Jump to solution

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

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

image.png

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

image (1).png

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

image (2).png

 

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.

image (3).png

 

0 Kudos
1 Solution

Accepted Solutions
Lesley
Leader Leader
Leader

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

-------
If you like this post please give a thumbs up(kudo)! 🙂

View solution in original post

11 Replies
AkosBakos
Advisor

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

----------------
\m/_(>_<)_\m/
0 Kudos
SecurityNed
Collaborator

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.

0 Kudos
AkosBakos
Advisor

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

----------------
\m/_(>_<)_\m/
0 Kudos
SecurityNed
Collaborator

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

0 Kudos
AkosBakos
Advisor

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

 

----------------
\m/_(>_<)_\m/
0 Kudos
SecurityNed
Collaborator

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.

0 Kudos
the_rock
Legend
Legend

Can you send this please?

clish -> show web ssl-port

Andy

0 Kudos
Lesley
Leader Leader
Leader

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

-------
If you like this post please give a thumbs up(kudo)! 🙂
_Val_
Admin
Admin

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

 

0 Kudos
Lesley
Leader Leader
Leader

Thanks edited my post

-------
If you like this post please give a thumbs up(kudo)! 🙂
0 Kudos
SecurityNed
Collaborator

Update guys!

I was able to resolve this one, it just magically works for some reason. The problem right now is URL filtering is not working anymore after transitioning to a 2 tier setup. 

Everyone, thank you for the assistance!


0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events