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.
With the session helper enabled the DNS resolution being caught in the FortiGate will be visible for that object.
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
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.
