Skip to main content
lbruno
Staff
lbruno
Staff
June 7, 2021

Technical Tip: FQDN Wildcard address is not resolved when using it in Firewall Policies

  • June 7, 2021
  • 0 replies
  • 17036 views

Description

 

This article describes a potential reason to explain why the user-defined FQDN Wildcards may not be working as expected.

It is possible that a scenario where an FQDN Wildcard object is created, and although it is used in a firewall policy, the traffic is not being matched to the policy using the FQDN wildcard object. This can occur if there is no UDP DNS session helper enabled, as the FortiGate will lose visibility into the DNS traffic in order to build list of IP addresses that match the wildcard of the FQDN object.

This helper is enabled by default, but it may have been removed , this setting is required to be enabled for FQDN objects to function correctly.

Scope

FortiGate.

Solution

 

Consider the following session helper configuration:

And the following firewall rules, one to allow DNS queries to flow through FortiGate and a second one to allow domain *.fortinet.com to use a wildcard: Technical Tip: Using a wildcard FQDN.
 
 
With the session helper enabled, DNS traffic is intercepted by the FortiGate allowing visibility into DNS queries matching that object: Technical Tip: Using a wildcard FQDN.
 
For v7.0 and later:
diagnose firewall fqdn list-all | grep fortinet
fqdn_u 0x56304302d749 www.fortinet.com: type:(1) ID(251) count(1) generation(3) data_len:13 flag: 1
 
It will be possible to reach a website within that domain, such as kb.fortinet.com.
 

 

But if the UDP DNS session helper is not present, the FortiGate will lose visibility into the DNS traffic , and building a list of DNS resolution matching that object will not be possible, and an empty FQDN list will be visible instead.

When dns-udp session helper is not configured, there will be a warning message when trying to configure cache-TTL on the wildcard FQDN firewall address: Warning: no dns-udp helper, wildcard FQDN may not resolve.

 

JeanPhilippe_P_0-1761664946317.png

 

To resolve this, dns-udp helper has to be configured (it is already configured by default):

 

config system session-helper

    edit 14

        set name dns-udp

        set protocol 17

        set port 53

end

 

As a consequence, that URL or any other URL matching that wildcard will be dropped by the implicit denied rule.

 
Note: If the DNS query from an endpoint is made to an internal DNS server and this DNS traffic does not pass through the FortiGate, then the query from the DNS Server to the Forwarder (could be internal or external), to resolve the FQDN, has to go through the FortiGate, so FortiGate can cache the resolution and update the wildcard FQDN object.
 
Extra Tip:
FQDN Wildcards do not always keep up with cloud services whose IP addresses change constantly. In these cases, relying solely on FQDNs can block or drop traffic unexpectedly. For those scenarios , consider combining FQDNs with IP-based objects or dynamic updates so the firewall always allows the right traffic.
 
Related articles:
Terms & ConditionsAccessibility statement