Description
This article describes how 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 allowed.
This usually happens if there is no UDP DNS session helper enabled, as the traffic will not be correctly matched because DNS resolution will not be performed properly.
This helper is enabled by default, but it may have been removed for some reason, so always check before using FQDN Wildcards.
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, the DNS resolution being caught in the FortiGate will be visible for that object: Technical Tip: Using a wildcard FQDN.
It will be possible to reach a website within that domain, such as kb.fortinet.com.
But if, for some reason, the UDP DNS session helper is not present, the resolution will not be possible, and an empty FQDN list will be visible:
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.
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. To stay safe, combine FQDNs with IP-based objects or dynamic updates so the firewall always allows the right traffic.
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. To stay safe, combine FQDNs with IP-based objects or dynamic updates so the firewall always allows the right traffic.
Related articles:
