We've attempted to use FQDNs for traffic such as SIP, SFTP, etc., but the rules don't receive any hits. If we include the IPs within the same rules, the traffic starts to flow. Our previous firewall would resolve the FQDNs to IPs for non-web traffic, but the FortiGates don't seem to be behaving this way.
I'd like to confirm that FQDNs only work with web traffic, and if it should work with other traffic, are there any tricks to the configuration?
Thanks
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
ya they do loadbalancing obviously ;)
I'd suggest using the FGT ISDB for those instead of FQDN.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
I suppose your problem is not the FQDN itself but DNS. You have to make sure that the FGT System DNS is set to a DNS Server which can resolve your internal FQDNs properly to make it work.
Per default FGT use the FortiGuard DNS Servers which probably will not resolve your internal FQDNs.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Hi @albaker1
Can you share the policy configuration on the firewall, and also the FQDN details.
Is the FQDN resolving on the firewall or not ?
You are initiating the SIP traffic based on IP address or you have defined the FQDN, so while traffic is being initiated for VOIP so is your end device able to resolve the FQDN.
Thanks
The FQDNs are resolved by the FGT and client, but the FGT is not getting the same IP. **Both are using the same DNS server.** I suspect that however the FGT is resolving the wildcard FQDN, the server is using a specific FQDN that resolves different.
This is pretty typical. The FTG resolves *.windowsupdate.com to 14 different IPs, which starts off as follows:
fqdn_u 0x10288e41 *.windowsupdate.com: type:(1) ID(241) count(14) generation(43) data_len:182 flag: 1
ip list: (1 ip in total)
ip: 209.197.3.8
ip list: (1 ip in total)
ip: 23.47.51.58
ip list: (1 ip in total)
ip: 23.47.51.59
...
and *.microsoft.com to the following:
fqdn_u 0x10287dd0 *.microsoft.com: type:(1) ID(10) count(39) generation(989) data_len:507 flag: 1
ip list: (1 ip in total)
ip: 20.189.173.4
ip list: (1 ip in total)
ip: 20.189.173.6
ip list: (1 ip in total)
ip: 209.197.3.8
The server is trying to connect to <blah>.windowsupdate.microsoft.com, which resolves to a 42.x.x.x IP address, which is NOT in *.microsoft.com IP list on the FTG. I'm taking back what I said about http and https working. I was told it was a few days ago, but another ticket was opened up. No protocol is working at this point for FQDN, so I take it the URL is not inspected for web traffic - the FortiGate resolves the FQDN to some IPs, and makes it decision on that. For updating Windows, I included all FQDNs that are a part of Microsoft and Windows updates, and it still isn't working - the WSUS servers are still trying to hit Microsoft IPs that the FortiGate doesn't have. Same for the SIP traffic - the IPs in the FortiGate are not what the SIP PBXs resolve.
ya they do loadbalancing obviously ;)
I'd suggest using the FGT ISDB for those instead of FQDN.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
This resolved the issue. Thank you.
Does the policy work fine when you use a non-wildcard FQDN?
I guess yes, since FGT resolves it with a simple DNS query.
Windcard is a bit more complicate since FGT initially can't have all subdomains or IPs associated with *.microsoft.com.
Understand this. Since wildcards could be used, I wasn't sure if the FTG somehow crawled (?) DNS records - without doing something like this, I don't understand that value of even using them. The ISDB was the solution though. Thanks for your time.
Additionally regarding wildcard FQDN..
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Using-wildcard-FQDN/ta-p/196118
This article is was I tried prior to starting the conversation. It appears to me the FortiGate cannot resolve any, or at least most, of the sub-FQDNs under the wildcard FQDN. At this point, I'm adding newly found FQDNs and IPs/subnets to make the connections work. Thanks for your time, though.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.