Fortigate 200B NSlookup

[Thirst4Knowledge]

Hi Guys, Is there an NSlookup command or equivilent on the CLI for the fortigate ? We need to have the firewall resolve dns addresses for hosts rather than having to put hundreds of IP addresses for our Office 365 Migration. Im sure the Fortigate is capable of doing this but some of my collegues think it cant. I think this is sill because you have the FQDN option in the address menu They only way I can prove it full is by using the NSlookup command and get advise from you guys ! Its a 200B v4.0,build0441,110318 (MR3)

[romanr]

Hi, there is no nslookup command on the fortigate :( - there is on fortimail... " exec ping" will resolve hostnames - so this is normally enough for testing as you normally won' t need more then A or AAAA records being looked up on a firewall! You can use FQDN addresses in the firewall policies.. best regards, Roman

[Thirst4Knowledge]

damn, had that feeling. A ping will have to do I also di a " diagnose firewall fqdn list" but im not sure if that just shows the fqdn list I put in or if that shows it is using fqdn for the addresses behind them

[romanr]

" diagnose firewall fqdn list" will show you which FQDN addresses are being used and to which IP addresses they resolve(d) ... you can clear DNS cache for FQDN addresses as well with " diagnose firewall fqdn flush" br, Roman

[Thirst4Knowledge]

Great thanks for the info !!

[Thirst4Knowledge]

I just had a thought.. I looked at the DNS settings on the firwall and I noticed that it was using internal DNS servers .... now lets say these servers are flakey linux boxes and may not have the microsoftonline.com in there dns records... this will cause a problem unless these are updated or I use external DNS servers

[rwpatterson]

ORIGINAL: Thirst4Knowledge .... now lets say these servers are flakey linux boxes and may not have the microsoftonline.com in there dns records...

Bite your tongue! The boxes are only as ' flaky' as the persons that configured them. ;) If the forwarders are configured correctly there should be no issues with using internal Linux boxes.

[Thirst4Knowledge]

he he :) Well, everyone else is still convinced that the Fortigate was the issue. They claim that once they put in IP addresses rather than DNS names that it started working. here are the DNS nsames I have configured for MS O365: microsoftonline.com testexchangeconnectivity.com secure.shared.live.com outlook.com livemeeting.com lync.com sharepoint.com I haven' t got a leg to stand on at the moment :(

[rwpatterson]

Can you resolve those from the work stations? If no, change the server to the FGT, and try again. (inside nslookup, type ' >server <fgt_IP>' )

[Thirst4Knowledge]

yeh the names resolve on the work stations. Doing more digging and it turns out: because the main O365 rule on the Fortigate was using wildcard domain names and neither the FQDN nor the IP address, the firewall doesn’t know how to handle those. When we are using the web filtering UTM feature in the Fortinet (essentially using it as a proxy), it will look at the host header in the packet and allow or deny based on finding a partial string match. we don’t use the web filtering feature, so the fortigate is forced to look at the IP address that the user is going to, do a reverse lookup on it and allow or deny based on the exact name that comes back in the PTR DNS record. So if the rule has outlook.com as an allowed destination, the user is going to IP 157.56.240.137, and the firewall does a lookup on this address and it comes back with autodiscover.outlook.com, it doesn’t see it as a match When we are using the web filtering UTM feature on other fortigates in the company that have the licnce for the web filtering UTM feature on the Fortinet (essentially using it as a proxy), it will look at the host header in the packet and allow or deny based on finding a partial string match