| Description |
This article describes some of the functional differences between using Internet Service database objects vs. FQDN Address objects in FortiGate Firewall Policies. In particular, an example scenario is given where the difference in behaviors caused an impact to users trying to connect Microsoft Outlook for email. |
| Scope | FortiGate. |
| Solution |
As a primer, FQDN Address objects work by taking a configured fully-qualified domain name (such as outlook.office365.com) and having the FortiGate resolve the IP addresses associated with that FQDN. There also exist Wildcard FQDN objects, where the FortiGate instead passively monitors DNS queries as they pass through and adds IP addresses to the Wildcard FQDN if they match the pattern.
In both cases, these objects can be as Sources/Destinations in Firewall Policies, and the FortiGate will check incoming connections against the list of IP addresses resolved and associated with these FQDN objects.
However, there are certain situations where FQDN objects can run into issues, such that users are not able to access services through Firewall Policies that use them. For example:
In these situations, a better alternative may be to use an Internet Service database object instead. ISDB objects can be more reliable in this situation since they contain a list of IP address ranges, ports, and protocols that are dynamically updated by FortiGuard, and they often have more thorough coverage than individual FQDN objects do.
Example Scenario: In this example, users were experiencing intermittent issues with accessing Microsoft Outlook through the FortiGate. The following shows the Firewall Policy that is currently configured, and it uses an FQDN Address object in the Destination field:
As part of troubleshooting, the implicit_deny policy temporarily had Log IPv4 Violation Traffic enabled, and the Forward Traffic logs showed that when users were experiencing issues, the connections were being matched to implicit_deny.
In the above example, 20.105.73.143 was the destination IP address that did not match the main Firewall Policy. When checking the Internet Service database, it was determined that the IP address did match a list of Microsoft services:
FortiGate # diagnose internet-service match root 20.105.73.143 255.255.255.255 Internet Service: 327786(Microsoft-Azure), matched entry num: 2, matched num: 2 Internet Service: 327681(Microsoft-Web), matched entry num: 4, matched num: 4 Internet Service: 327682(Microsoft-ICMP), matched entry num: 2, matched num: 2 Internet Service: 327683(Microsoft-DNS), matched entry num: 2, matched num: 2 Internet Service: 327684(Microsoft-Outbound_Email), matched entry num: 4, matched num: 4 Internet Service: 327686(Microsoft-SSH), matched entry num: 1, matched num: 1 Internet Service: 327687(Microsoft-FTP), matched entry num: 2, matched num: 2 Internet Service: 327688(Microsoft-NTP), matched entry num: 2, matched num: 2 Internet Service: 327689(Microsoft-Inbound_Email), matched entry num: 4, matched num: 4 Internet Service: 327694(Microsoft-LDAP), matched entry num: 4, matched num: 4 Internet Service: 327695(Microsoft-NetBIOS.Session.Service), matched entry num: 2, matched num: 2 Internet Service: 327696(Microsoft-RTMP), matched entry num: 2, matched num: 2 Internet Service: 327704(Microsoft-NetBIOS.Name.Service), matched entry num: 1, matched num: 1 Internet Service: 327680(Microsoft-Other), matched entry num: 2, matched num: 2
With the above in mind, the Firewall Policy was modified to use an Internet Service Database object instead of the existing FQDN Address object. Multiple objects were selected based on the service being utilized (Outlook-based email), such as Microsoft-Azure, Microsoft-Outbound_Email, and Microsoft-Inbound_Email:
After the policy was modified, Outlook traffic now reliably matched the expected Firewall Policy:
Related articles: Technical Note: Internet Service Database - List of services, IP ranges, ports and protocols |
