FQDN Objects & IPv4 Policy

[Mikelar]

I'm setting up a 100D that will replace our aging firewall, and I'm trying to use the IPv4 policy to allow traffic to FQDNs, specifically LogMeIn.

I'm using the address object below:

[ul]

Name: LogMeIn_1

Type: FQDN

FQDN: *.logmein.com

Interface: any[/ul]

IPv4 Policy below:

[ul]

From: lan

To: wan1

Source: all

Destination: LogMeIn_1

Schedule: always

Service: HTTP, HTTPS

Action: Accept

NAT: enable[/ul]

My issue is that traffic isn't hitting his policy. LogMeIn remains blocked until I change the destination to 'all'. In the forward traffic log I can see the below items being denied:

216.52.x.x (control.app0x-x.logmein.com) - HTTPS - deny

To me this should fall within the above policy. I'm at the stage where I'v stripped all other policy rules just to focus on LogMeIn, to see where I'm going wrong.

I'm thinking it may be due to the way the DNS is resolving. I've also got a number of other LogMeIn FQDN objects that LMI uses (logme.in, etc), but I'm focusing on logmein.com as the above settings should be allowing it. I do not have any UTM features such as Application or Web filtering enabled at this time. There is only 1 host on the lan interface, and it's getting IP/DNS settings from the firewall.

Firmware v5.2.2,build642 (GA).

Any suggestions would be very much appreciated.

[MikePruett]

Yeah wildcard FQDN on 5.4.1 is no bueno so far. Major bummer too.

[CyberNorris]

MikePruett wrote:

Yeah wildcard FQDN on 5.4.1 is no bueno so far. Major bummer too.

Not being able to use them in policies is a hinderance. I created an address group that contains both FQDN and Wildcard FQDN entries and even it is not visible for use by a firewall policy.

I've discovered that Wildcard FQDN is available for SSL Inspection profiles. Haven't had a chance yet to test on other security profile types.

A quick search of the docs doesn't reveal any restrictions on the use of Wildcard FQDN, but the same instruction on creating a Wildcard FQDN is available in both the Firewall Handbook for FortiOS 5.4.1 and FortiOS Handbook for FortiOS 5.4.1. You'd think that if it was in the Firewall Handbook for FortiOS 5.4.1, that it would be available for use in the firewall.

I'm asking support and other resources for information on when we can expect the use of Wildcard FQDN to be available in policies.

[mok]

Any news of this ?

[scerazy]

That is absolutely tragic!

How in 2018 I can not use wildcard FDQN in exceptions is beyond me!

I need to DNS whitelist *.msappproxy.net for use with Azure Active Directory Seamless Single Sign-On

I really do not need hundreds of lines of IP address ranges (it is difficult to maintain and even creat in first place, as there is not batch faility)

Shame on you Fortinet with your lazy coders!

[PiniPunk]

Someone knows if it's possible use wilcard FQDN in policies with FortiOS 5.6?

[scerazy]

Do like this

It works fine, I use it all the time when I need to exempt some domain (for whatever reason)

edit:

It does NOT work. Such policy allows EVERYTHING OUT. The above blog is plain wrong or the guy tested on some version of FortiOS that behaved different

[smashingly]

Scerazy, I've just tried that approach on a FW60E with 6.0.1 and it worked fine for me.  I took this approach:

[ol]

Attempt connection to outlook.office.com and google.com = fails

Configure webfilter profile allowing 10 or so Microsoft wildcard FQDNs (e.g. *.microsoftonline.com etc) as specified by Microsoft help docs.

Create policy allowing my test host (on LAN interface) to ANY (on WAN interface), with any service, with Web Filter enabled.

Attempt connection to outlook.office.com = succeeds, I get auth page.  Attempt connection to google.com = fails.[/ol]

It was a basic pretty quick test, but it proved to me that it's a workable solution.  My biggest pain-point is a large customer deployment where their Skype for Business servers need to talk to a gazillion Microsoft Office365 hosts, and people have deployed various wildcard FQDNs in various firewall rules believing that it works (but it doesn't, as we've all discovered in this forum!) - I have implemented a rule based on a gazillion address objects representing all the known Microsoft datacentre IP ranges for the regions in use by us (Australia East & SouthEast) which gets it working, but as Microsoft likes to reallocate their IP address ranges globally on a regular basis, it's risky and needs to be kept up to date.  I'm investigating webfilters as a way around that.  But what I'm curious about is whether webfilters work with applications that aren't web browsers (e.g. Skype for Business talking to an O365 server on port 443).  Is the Webfilter feature just a dynamically-updated IP address filter, or does it inspect traffic more than that, expecting to see http browser headers etc?   (in other words, if I was to try to push another protocol like RDP over tcp/443, would the webfilter approach still work?)