Zero Phishing - will it work without FQDN configured on SecGW?

[jdoe1979]

Hi,
Testing the 81.20 in the lab and since there's no FQDN configured on SecGW the JS script won't load to the browser (fails to resolve)
So is it a hard requirement? There's no mention of it in the documentation that I could find...
I've setup a hostname via Gaia portal but that didn't fix it. 

UPDATE:
After standing up a DNS server browser still can't download the script.

this time error is

GET https://server.checkpoint.local/zph/js/zp.js?api_key={XXXXXXX-0002-5648-A0A0-XXXXXXXX} net::ERR_CONNECTION_REFUSED

[the_rock]

Maybe someone from CP can confirm, but Im 99.99% sure it is a hard requirement. I will try "crack" it in my lab as well, but no luck so far 🙂

Plus, you need https inspection for it to work to begin with, as probably 99% of the sites now days are https.

[jdoe1979]

i don't mind the https but this fqdn requirement is bit odd...

[the_rock]

Just my logical thinking, but the key is what I pointed out...for BEST protection...

Andy

 

[jdoe1979]

doesn't that kinda imply in browser protection can work without FQDN?

[the_rock]

True, I get your point, but I also get what @PhoneBoy is saying. I would confirm 100% with TAC, though Im fairly certain zero phishing will never work without valid FQDN.

[the_rock]

You can overcome this by typing www.google.com (does not even matter what website is there), but obviously it probably wont work once you push policy, because your gateway IP wont resolve to that fqdn. I may test after making the change by giving my windows VM the default gateway of my R81.20 gateway.

[jdoe1979]

won't do as it will then go and GET request the script from the FQDN Url.

[the_rock]

Agreed!

[PhoneBoy]

It’s expected that all security gateways and management have functional DNS server(s) configured.
This isn’t a requirement that’s specific to Zero Phishing.

[jdoe1979]

i mean that without domain name assigned to SecGW Zero Phishing doesn't work.
Browser fails to resolve  URL to grab the script.
I got it configured, but now it's 
GET https://server.checkpoint.local/zph/js/zp.js?api_key={XXXXXXX-0002-5648-A0A0-XXXXXXXX} net::ERR_CONNECTION_REFUSED

[Sprunknwn · Accepted solution]

Hi there jdoe1979,

FQDN is currently required for the full operation of the blade.
You can enable Zero Phishing without HTTPSi but that would negate most of the benefit the blade provides as most websites are HTTPS nowadays.
If you want to fix your issue in the lab, you can either configure a new record in your DNS server so the end clients will be able to resolve the FQDN entered in Zero Phishing configuration or you can manually edit the hosts file on your client/s with the FQDN you entered in Zero Phishing configuration and the IP of the interface facing the client.

We are working on a solution that will require no configuration from the admin and it will just be click and play, so to speak.

Let me know if you have any more questions.
Thanks,

Hertsel

[jdoe1979]

Appreciate the clarification,

What about the error message I'm seeing? 

GET https://server.checkpoint.local/zph/js/zp.js?api_key={XXXXXXX-0002-5648-A0A0-XXXXXXXX} net::ERR_CONNECTION_REFUSED

That's after standing up a DNS server and configuring FQDN on SecGW

[Sprunknwn]

Hey jdoe1979,

Are you able to test the ZPH portal on the GW using the test URL - https://<FQDN>/zph/zp-test.html

If you are able to access it, run a test to check the feature works correctly with the following website - https://zp-demo.com/verification/zphi_check.html

If any of those fail, I suggest to open a ticket with support for further debugging.

Let me know how it goes.

Thanks,

Hertsel

[jdoe1979]

yeah so it's not working and I got sent to 
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

And tada - ZPH doesn't work without Public IP.

This is truly an alpha release feature...

I'm gonna wait till they actually get this thing documented and running as prescribed.

[PhoneBoy]

The way I read this SK is that the limitation itself comes from the browser, not something we impose as a result of our implementation.
And it only applies to HTTP (not HTTPS) traffic.

Which means a TAC case is definitely in order here so we can see what's really going on.

[the_rock]

Thanks for that explanation @Sprunknwn . I think its great info when someone asks about it.

Have a nice day!

Andy