FQDN in R80 Policy Access rule

[Sammo_Li]

Hi All Experts,

   I would like to know if R80 support FQDN as the source/destination in the access rule?If yes, how is it working? Thanks

Sammo

[Limor_Ganon · Accepted solution]

Hi,

in R80.10 domain objects support FQDN mode, so you could define a domain object, and mark it as FQDN.

Note:

1. This is supported only from R80.10 GW

2. In R80.10 domain objects have much better performance as they no longer disable accept templates.

Best Regards,

Limor

[Sammo_Li]

Thanks for your reply Limor. Just want to know a little more about the mechanism. If I put the domain object into an Access Rule. When a user go to a server, the GW will only see the server IP but not the FQDN.

The GW will do a reverse DNS lookup of the IP or other way to know the FQDN of the IP? (Such as HTTP host field).

Many thanks

Regards,

Sammo

[Meital_Natanson]

Hi,

In general, it's correct - we have the destination IP and do reverse DNS request to get the domain name.

But, if all domains objects in policy are FQDN mode - we don't have to perform reverse DNS requests.

We simply keep a cache [IP->Domain Name] and fills it with IPs that we get from direct DNS resolving of the domain objects that are used in the policy [We re-send direct resolving request every 30 seconds (configurable) to collect all IPs]

Then, we have the destination IP and search for the domain name in the cache.

If there is at least one domain object that is not FQDN - then, if we won't find the IP in the cache, we will do a reverse DNS request to get the domain name and check if it's a sub-domain of one of the objects in the policy.

Regards,

Meital

[Brian_Deutmeyer]

This is great news!  Out of curiosity, is there a way to query the cache on the gateway to see what it thinks the FQDN should resolve to?   Just looking for some basic troubleshooting steps. Thanks!

[Duyen_Ngo_Van]

Could Checkpoint do a FQDN like this: *.checkpoint.com ?

[Meital_Natanson]

In R80.10 - Yes.

When you define a domain object - you can choose if you want FQDN or not.

FQDN for checkpoint.com will be matched on traffic for checkpoint.com only.

Non-FQDN will be matched for *.checkpoint.com sub-domains.

Regards,

Meital

[Shehan_Wickrama]

https://community.checkpoint.com/people/meita5ded0c4b-2998-32d8-a627-37bb680eeb5d‌

If i define .checkpoint.com as my domain object and tick off FQDN option to make it a wildcard domain and then if i add 2 A records like

   test.checkpoint.com (8.8.8.8)

   test2.checkpoint.com (8.8.4.4)

I can't ping to above mentioned A records but I can ping to checkpoint.com. What changes should I make to get the above scenario working.

FYI: Take 42 HF applied

[PhoneBoy]

The FQDN option uses forward DNS lookups (DNS name to IP mapping)

As there is no way to do a forward lookup of a wildcard, you must list the explicit FQDNs.

This option is SecureXL friendly and supported in R80.10+ gateways.

Unchecking the FQDN option will use reverse DNS lookups (IP to DNS name mapping), which will work with all versions.

However, this option often produces inaccurate results as many sites use IPs that do not map to the expected DNS names.

Just as an example:

dwelch@host:~$ nslookup google.com

Server: 8.8.8.8

Address: 8.8.8.8#53

Non-authoritative answer:

Name: google.com

Address: 172.217.11.174

dwelch@host:~$ nslookup 172.217.11.174

Server: 8.8.8.8

Address: 8.8.8.8#53

Non-authoritative answer:

174.11.217.172.in-addr.arpa name = lax28s15-in-f14.1e100.net.

Authoritative answers can be found from:

dwelch@kermit:~$

[Shehan_Wickrama]

Thank You Welch!

[Dave_Taylor]

So if an R80.10 gateway can do DNS lookup based on FQDN then does that then mean for O365 and Azure you can just provide *.microsoft.com instead of the 4000+ network/ips that are currently required to bypass SSL inspection?

[PhoneBoy]

It's a few more domains than that as I recall.

Even so, I don't believe Domain Objects are supported with the HTTPS Inspection rulebase.

That said a solution to this problem is planned for the near term (post R80.10).

[Limor_Ganon]

Indeed domain objects are not available in HTTPSI policy (should be supported in upcoming version/s).

Also - for FQDN, you need to specify the exact fully qualified domain (with no wildcard).

As for office 365 - we are now in the process of releasing a HF on top of R80.10 (jumbo 24) that allows to use dynamic objects that represent office 365 services.

Currently this HF is in EA phase. 

If this may interest you - please contact me directly.

Thanks,

Limor

[Vladimir]

Limor,

Any idea when this HFA is going GA?

Thank you.

[Limor_Ganon]

Hi,

This HF is currently in EA stage. More information about it is available in sk119562  (currently internal).

Once there are enough EA deployments, we will release it as public.

If you would like to install it in EA stage - please contact your SE.

Thanks,

Limor

This