- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- GAiA Shows "Site cant be reached" - Logs show its ...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you send this please?
clish -> show web ssl-port
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Lesley you did not specify any SK, or am I blind?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks edited my post
If you like this post please give a thumbs up(kudo)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!