Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
albaker1
Contributor

Using FQDNs for non-web traffic

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

1 Solution
sw2090
Honored Contributor

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

View solution in original post

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
9 REPLIES 9
sw2090
Honored Contributor

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

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
asengar
Staff
Staff

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

@bhishek
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
Honored Contributor

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

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
albaker1

This resolved the issue. Thank you.

AEK
Honored Contributor

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.

AEK
AEK
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
Honored Contributor

AEK
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.

Top Kudoed Authors