Using FQDNs for non-web traffic

[albaker1]

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

[sw2090]

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.

[asengar]

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

[albaker1]

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.

[sw2090 · Accepted solution]

ya they do loadbalancing obviously ;)
I'd suggest using the FGT ISDB for those instead of FQDN.

[albaker1]

This resolved the issue. Thank you.

[AEK]

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.

[albaker1]

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.

[AEK]

Additionally regarding wildcard FQDN..

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Using-wildcard-FQDN/ta-p/196118

[albaker1]

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.