Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Sammo_Li
Employee Alumnus
Employee Alumnus
Jump to solution

FQDN in R80 Policy Access rule

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

0 Kudos
1 Solution

Accepted Solutions
Limor_Ganon
Employee Alumnus
Employee Alumnus

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

View solution in original post

0 Kudos
14 Replies
Limor_Ganon
Employee Alumnus
Employee Alumnus

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

0 Kudos
Sammo_Li
Employee Alumnus
Employee Alumnus

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

0 Kudos
Meital_Natanson
Employee
Employee

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
Collaborator

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!

0 Kudos
Duyen_Ngo_Van
Participant

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

0 Kudos
Meital_Natanson
Employee
Employee

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
Collaborator

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

0 Kudos
PhoneBoy
Admin
Admin

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
Collaborator

Thank You Welch!

0 Kudos
Dave_Taylor
Explorer

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?

0 Kudos
PhoneBoy
Admin
Admin

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).

0 Kudos
Limor_Ganon
Employee Alumnus
Employee Alumnus

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
Champion
Champion

Limor,

Any idea when this HFA is going GA?

Thank you.

0 Kudos
Limor_Ganon
Employee Alumnus
Employee Alumnus

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

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events