FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
vpereira
Staff
Staff
Article Id 196118

Description

 

This article describes the usage of wildcard FQDN.

 

Scope

 

Any supported version of FortiGate.

Solution

 

Support for wildcard FQDN addresses in firewall policy has been included in FortiOS 6.2.2.

A wildcard FQDN can be configured from either the GUI or CLI.

From the GUI:

Go to Policy & Objects -> Addresses -> New Address.
In the screenshot below, *.fortinet.com is used as a wildcard FQDN.

 
From the CLI:

config firewall address

    edit "fortinet-fqdn"
        set uuid 96c22534-8a3b-51ea-ad68-98a463172306
        set type fqdn
        set fqdn "*.fortinet.com"
    next
end
 
A firewall policy needs to be defined to use a wildcard FQDN.

config firewall policy

    edit 8
        set name "fqdn-policy"
        set srcintf "port9"
        set dstintf "port1"
        set srcaddr "all"
        set dstaddr "fortinet-fqdn"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable
    next
end
 
When the wildcard FQDN has been configured, it will show as an unresolved FQDN in the firewall address list.
As compared to the standard FQDNs, the wildcard FQDN does not use system DNS settings (Network -> DNS).
The wildcard FQDN is updated when a DNS query is made from a host connected to FortiGate (DNS traffic passing through a FortiGate).
If the query matches the wildcard FQDN, the IP address is added to the cache for that object on the FortiGate.
 
 
The wildcard FQDN is updated if a DNS query is done using either FortiGuard DNS servers or internal DNS servers or any public DNS server.
If internal DNS servers are used, the DNS traffic passes through the FortiGate.
The response from the query is then populated to the FQDN object.
 
diagnose firewall fqdn list | grep fortinet
*.fortinet.com: ID(48)
 
For updating the FQDN with IP addresses, running 'nslookup' from a host connected to a FortiGate will manually resolve each wildcard entry and the list will be populated with new IP addresses as shown below.

Note that all IP addresses are assigned to that wildcard FQDN object for an unlimited time by default.
If FortiGate is rebooted, all IP addresses has to be learned again.
 
If it is necessary to limit TTL, this is possible from the CLI and configurable per object:
 
diagnose firewall fqdn list | grep fortinet
*.fortinet.com: ID(48) ADDR(208.91.113.75) ADDR(208.91.113.80) ADDR(208.91.113.85) ADDR(34.228.249.126) ADDR(34.226.137.150) ADDR(96.45.36.159)
 
Some of the domains (for example, google.com) have very short TTL and resolve to different IPs for different requests to implement DNS based load balance. This will result in a discrepancy between the IP resolved by FortiGate and the other IP resolved by the host. A workaround for this issue is to set a large cache-ttl so that IP addresses will be saved longer even when their TTLs expire.

config firewall address

    edit "wildcard.google.com"
        set type fqdn
        set fqdn "*.google.com"
        set cache-ttl 86400       
    next
end
 
Sometimes it a new DNS query replaces the existing entries learned from FortiGate.

Consider the example below:

diagnose test application dnsproxy 6

vfid=0 name=*.google.com ver=IPv4 min_ttl=37:0, cache_ttl=0 , slot=-1, num=4, wildcard=1
172.217.1.164 (ttl=94:0:0) 172.217.164.205 (ttl=114:0:0) 172.217.1.14 (ttl=106:0:0) 172.217.164.238 (ttl=37:0:0)
 
Performing an nslookup for mail.google.com replaced all 4 entries above.
 
nslookup mail.google.com

> mail.google.com
Server: dns.google
Address: 8.8.8.8

Non-authoritative answer:
Name: googlemail.l.google.com
Addresses: 2607:f8b0:400b:809::2005
172.217.165.5
Aliases: mail.google.com

diagnose test application dnsproxy 6
vfid=0 name=*.google.com ver=IPv4 min_ttl=41:0, cache_ttl=0 , slot=-1, num=2, wildcard=1
172.217.1.174 (ttl=255:0:0) 172.217.165.5 (ttl=263:221:221) Then, nslookup drive.google.com- IP 172.217.1.174 is replaced.
> drive.google.com

Server: dns.google
Address: 8.8.8.8

Non-authoritative answer:
Name: drive.google.com
Addresses: 2607:f8b0:400b:800::200e
172.217.164.206

diagnose test application dnsproxy 6
vfid=0 name=*.google.com ver=IPv4 min_ttl=110:0, cache_ttl=0 , slot=-1, num=2, wildcard=1
172.217.165.5 (ttl=263:85:85) 172.217.164.206 (ttl=299:275:275)
 
The IP addresses are replaced because they have already expired.

ttl = 106:0:0 is the original TTL:time to expire in TTL:time to expire in cache.

The latter two are the same if the cache-ttl is not set in the address.

In FortiOS 7.4.0 and above, the 'fqdn-max-refresh' timer can be modified.

 

The 'fqdn-max-refresh' setting is utilized to set the global upper limit for the FQDN refresh timer. If any FQDN entries have a TTL interval longer than the 'fqdn-max-refresh' value, their refresh timer will be reduced to this predefined upper limit. By using this setting, the FortiGate can control the maximum interval for querying DNS updates for its FQDN addresses, allowing more control over DNS caching behavior.

 

CLI Syntax:


config system dns

set fqdn-max-refresh <integer> -> FQDN cache maximum refresh time, in seconds (3600 - 86400, default = 3600).

end

 

 

Related article:

Support for Wildcard FQDN addresses in Firewall policy.