- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: FQDN - how does it work under the hood?
- 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
FQDN - how does it work under the hood?
hi,
I was asked today how FQDN objects work, especially when the client resolved the URL already in the LAN.
1. Assuming NON-FQDN mode
e.g.
- client resolves apps.apple.com from internal DNS server to IP address 95.1.1.1
- client forwards request to default router and then via firewall to internet
- The firewall has an NON-FQDN object apple.com which allows the traffic.
However, the firewall see the IP address and not the URL, correct?
Does the firewall always do a reverse DNS lookup to see if the destination IP is part of any FQDN object?
Default TTL = 60 seconds
The FQDN-A-Deeper-Dive-Customer.pdf did refer to older version.
https://community.checkpoint.com/t5/Management/Domain-Objects-FQDN-An-Unofficial-ATRG/m-p/40789/thre...
2. Assuming FQDN mode and destination www.apple.com
Default TTL = 3600 seconds
Does the firewall always do a reverse DNS lookup to see if the destination IP is part of any FQDN object?
Same question
Any idea?
Thanks; Regards
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, let's say your rule is: Source: 10.1.1.0/24 ; Dest: apple.com ; Service: https
If the gateway sees HTTPS traffic from a source 172.16.1.1 to any IP, the gateway does not do a lookup on the FQDN because the source cannot match the rule.
If the gateway sees SSH traffic from 10.1.1.1 to any IP, the gateway does not do a lookup on the FQDN because the service cannot match the rule.
If the gateway sees HTTPS traffic from 10.1.1.1 to any IP, the gateway DOES do a lookup for apple.com, because the connection could match the rule. If the destination IP matches the returned IP address from the lookup, the rule is matched. If it does not match, the rule matching continues down the policy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
sk90401: How are Domain Objects enforced by the Security Gateway?
sk161612: Domain Object Enhancement - DNS Passive Learning
sk157493: Fully qualified domain name object (FQDN) does not match properly, causing traffic drop
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi
thanks, I saw these SK but it did not answer the underlying question.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Open an SR# with CP TAC !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FQDN objects cause the firewall to look up the name periodically and cache the results in a table. The table is then used to populate the object. This works a lot like dynamic objects. For FQDN objects to work properly, the clients and the firewall must use the same DNS resolution path so they get the same answers. FQDNs do not involve any reverse lookup.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can confirm with TAC, but to me logically, I would say yes to both ?s
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Non-FQDN does a reverse lookup on IPs as they are seen to see if they match the URL defined. As such it's not the best tool as reverse lookups rarely match the URL used and it's a lot of DNS queries.
FQDN mode polls configured DNS servers every 60 seconds for the domain name configured and caches the result. Any traffic to the IP address that was resolved is matched against the FQDN object.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi,
I miss somehow the puzzle piece regarding the trigger:
..The firewall see the desired destination IP address and not the URL, correct?
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, the firewall sees packets from/to IP addresses with source/destination ports and makes decisions from there. Anything in a basic access policy (so no APPC/URLF) has to be matched to something based on that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi,
ok, that means if firewall only see the destination IP address, how does it know that it belongs to an access-rule when the is only a FQDN object like apple.com ?
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If the domain object is enabled in FQDN mode, the gateway is doing a DNS lookup every minute to resolve that to an IP address. When it sees a packet to that IP address, it matches against the FQDN object and will match the rule if everything else matches the rule criteria.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK,
means having hundreds of FQDN objects, DNS queries will be made independent if the is a current request?
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's performing the lookups when there might be a connection that could match the rule that contains the object.
When a connection that traverses the Security Gateway is being evaluated against the rulebase, if the Unified Policy mechanism encounters a possible match that includes a Domain Object, the object must be resolved before a verdict can be reached.
- If all Domain Objects in the Access Policy are in FQDN mode, the Security Gateway performs direct DNS resolution of each of the Domain Objects and caches the results
- If any domain object is not FQDN, and the IP address isn't in the cache, the Security Gateway must perform a reverse DNS request to determine whether the IP belongs to the Domain Object.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok,
Thanks. I'm afraid I still don't get it.
I still miss the trigger when the firewall sees only the destination IP request.
I guess, I will setup a TAC case.
Thanks a lot for your help!!
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, let's say your rule is: Source: 10.1.1.0/24 ; Dest: apple.com ; Service: https
If the gateway sees HTTPS traffic from a source 172.16.1.1 to any IP, the gateway does not do a lookup on the FQDN because the source cannot match the rule.
If the gateway sees SSH traffic from 10.1.1.1 to any IP, the gateway does not do a lookup on the FQDN because the service cannot match the rule.
If the gateway sees HTTPS traffic from 10.1.1.1 to any IP, the gateway DOES do a lookup for apple.com, because the connection could match the rule. If the destination IP matches the returned IP address from the lookup, the rule is matched. If it does not match, the rule matching continues down the policy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not so sure there's a traffic requirement to trigger the FQDN lookups. I have a standalone firewall I use as an API development target. All it has is a single External interface. It's looking up several of my FQDN objects (but not all) even though there's nothing behind it to be hitting any rules.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Excellent explanation!