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.

[Mikelar]

Thanks for your response. 

This was ultimately what I came to realize, I just didn't think that the update lag of the DNS table would be enough to render the rule ineffective.

The overall purpose for this rule was to allow a set of applications to bypass our proxy server. I'm now wondering how best to approach this policy. It seems the only way to avoid using LogMeIn subnet's in a policy rule is to create a rule to: allow all source, allow all destination, allow HTTP/S traffic. Although I have Application Control & Web Filtering enabled on this rule, it still seems like a VERY open rule to have in the policy.

Perhaps I'm over thinking it, but I'm just wanting to avoid potential security holes due to mis-configuration.

[AtiT]

Just some info: If you create an FQDN a DNS lookup will be done and you can check it via CLI whether the FQDN is working - the resolved IP address(es) and check wiht the traffic log whether the users are using the same IPs.

The * is not allowed:

LAB_LUX # diagnose firewall fqdn list List all FQDN: logmein.com: ID(88) REF(1) ADDR(77.242.193.199) ADDR(64.94.47.199) ADDR(69.25.21.199) *logmein.com: ID(130) REF(1) *.logmein.com: ID(176) REF(1)

[Dave_Berger]

When looking at a FGT with 5.2.4 we already thought that there might be some changes regarding wildcard support for FQDN address objects: there are several new objects (e.g. "*.dropbox.com" or "*.apple.com") which are preconfigured and referenced in the default SSL inspection profile. At first sight their DNS resolution seems to work:

fgt # diag fire fqdn list List all FQDN: [...]

*.gotomeeting.com: ID(103) REF(1) ADDR(216.115.208.197) [...] *.live.com: ID(117) REF(1) ADDR(65.55.60.123) [...]

*.googleapis.com: ID(239) REF(1) ADDR(74.125.140.95)

However, we checked the FQDNs mentioned above: in all three cases there is either an A or a CNAME record for "*.<domain>", which explains why the FortiGate can resolve these addresses. What we don't understand is why Fortinet explicitly points out in the documentation that for creating inspection exemptions address objects with wildcard character should be created, while in the KB they don't recommend it (because it obviously doesn't work the way you would expect it).

Regards, dave.

[nothingel]

I have been wondering the same thing about wildcard FQDN objects.  I posted a few weeks back but nobody responded. It's good to know that I'm not the only one curious:

https://forum.fortinet.com/tm.aspx?m=128436

[Dave_Berger]

My colleague has opened a ticket at Fortinet and has received the following answer:

The use of wildcard FQDN addresses within firewall policies is currently not supported. The FQDN addresses you find within the "config firewall address" section are used for excluding certain DNS domains by default from SSL/TLS deep inspection (see "config firewall ssl-ssh-profile" > "deep-inspection" > "config ssl-exempt"). Due to current design restrictions those addresses had to be put into the "config firewall address" section, but they won't work as expected when used in a firewall policy as source or destination. In the upcoming v5.4 there will be a separate type (wildcard-fqdn) for those address definitions to insure that they can't be selected/used within a firewall policy definition, but only with SSL exemption.

[nothingel]

This is very interesting!  Thanks for posting this.  I do wish, however, that upcoming code will avoid submitting those wildcard FQDN addresses to the DNS resolver.  According to my observations on 5.2.4, the firewall is constantly trying to resolve the wildcard FQDN objects.

[Dave_Berger]

I can confirm: in our test setup, the objects are only referenced in the SSL deep inspection profile, which isn't in use. Still we can see that at least some of the wildcard FQDN objects were resolved.

[mok]

The use of wildcard FQDN addresses within firewall policies is currently  STILL not supported on 5.4 That is very annoying !!!!

[Erwin]

mok wrote:

The use of wildcard FQDN addresses within firewall policies is currently  STILL not supported on 5.4 That is very annoying !!!!

Still not in 5.4.1. This makes the use of WAF impractical, as i need to exclude quite some domains from this filter.

[mok]

Thanks for feedback Erwin, I'm really disappointed for that! For me the use of Walled Garden is impractical too.