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.

[Dave_Hall]

Mikelar wrote:

I'm using the address object below:

[ul]

FQDN: *.logmein.com[/ul]

Wildcard entries are not allowed for FQDN address labels.  Since it's port 80/443 traffic, you may have better luck crafting a wildcard url filter for *.logmein.com -- add that to your main web filter profile (that's is covering your main web traffic policy). Set the url filter to allow.

[Mikelar]

Thanks for your response. 

I wasn't aware wildcard masks don't work in FQDN objects. I've also tested with different variations, including "logmein.com" without success.

Unfortunately I'm unable to enable Web Filtering at this time, as I'm waiting for the Contract Code for our support bundle from our re-seller. Once I have this I'll give this a try.

I'm still wondering why this setup isn't working, as it seems like a very basic rule. I'm sure I'm missing something simple, but I've had no luck finding it so far. We use a separate proxy server, so upon implementation we want to allow only HTTP/S traffic to originate only from the proxy server, and application traffic with a specific destination that will bypass the proxy server (including LogMeIn).

Again any further assistance would be greatly appreciated.

Further testing below:

Test 0 

Policy Rule allowing all traffic to FQDN object logmein.com

[ul]

Web Filtering disabled

Application Control disabled

IPv4 Policy as shown in attachment here.

Forward Traffic Log as shown in attachment here.

Result: LogMeIn blocked[/ul]

Test 1

Policy allowing only HTTP/S traffic to all destinations

[ul]

Web Filtering disabled

Application Control enabled as shown here.[/ul][ul]

IPv4 Policy as shown here.

Forward Traffic Log as shown here.

Result: LogMeIn working[/ul]

Test 2

Policy allowing all traffic to FQDN logmein.com

[ul]

Web Filtering disabled

Application Control enabled as shown here.[/ul][ul]

IPv4 Policy as shown here.

Forward Traffic Log as shown here.[/ul][ul]

Result: LogMeIn blocked[/ul]

[Dave_Hall]

@Mikelar

An expired contract would only affect the FortiGuard web filter service, the actual URL filter stuff should still work -- all you need to do is uncheck the FortiGuard Categories option in the Web Filter Profile.

Your screenshots are not showing the drilled-down/actual log info for the events...which would be helpful in determining the reason for the logged event. (e.g. blocking.)

This LogMeIn faq seems to imply white-listing a set of URLs (used with the service) is more suited than trying to "unblock" via IP addresses.  In their words, "Our IP ranges change regularly. For best results, please whitelist the URLs shown above."

[Mikelar]

Thanks again for your assistance, I appreciate the help.

@Dave

The domain names from LogMeIn are also what I'm going from. I've got a separate FQDN address object for each of their domains, (in 'domain.com' format), grouped under a group object named 'LogMeIn_Group'. I do have their IP list, but I'd prefer to use their FQDN's specifically for the reason mentioned on their site (they change regularly).

@emnoc

I initially tried using diag debug flow, but I wasn't getting much more detail than the log viewer. I've added some outputs from the latest round of testing.

Test 4

[ul]

All security features disabled (Application Control, Web Filter, Intrusion Prevention, Anti-Virus)

Test host 192.168.0.2 on interface 'TEST'

IPv4 Policy configured as shown here. Detail of the rule in question here.

Drilldown log entry shown here. This is the LogMeIn client software on the test host attempting to connect to LogMeIn.

Diag Debug Flow output for the same event as shown here.[/ul]

Result is the same, no connectivity and all traffic to logmein.com is being denied. The log and debug outputs show that the traffic is failing the policy check, which to me means that the traffic is not matching the rule. I just can't see what could be wrong with the rule in question. 

Test 5

[ul]

Same settings as above.

Added Subnet Objects to the policy in question (IP's given by LogMeIn Support that match the LogMeIn domains).

Result: Success[/ul]

I'm thinking that the LogMeIn client software on the test host is trying to connect using an IP rather than FQDN. Would this cause the traffic to fail the policy check, despite the IP being assigned to the logmein.com domain? 

If this is the case, is there a method to force the firewall to look up the FQDN during or before the policy check, so that the destination IP is matched to the FQDN?

Again, any assistance is greatly appreciated.

Cheers.

[Dave_Hall]

Personally, I'd would use a wildcard url filter (not FortiGuard web services) for what you are trying to accomplish.  Since your dilldown log shows the client trying to connect  via HTTP/HTTPS, I don't see how it wouldn't work. (Of course, I am assuming actual web traffic and not a port 80/443 data "tunnel".)

Regarding IP lookups for FQDN addresses -- I too was wondering about this since most of our clients are in remote areas with very slow satellite linkups.   Never found an actual official answer (of course I merely did a curiously check). I just ended up playing around with the cache-ttl values (from the CLI) for key FQDNs.

A side note, you could try moving your DNS firewall policy to the top of the firewall list.

[Mikelar]

Thanks Dave, again I appreciate your assistance.

After further testing and a big more digging I found a response here that looks pretty accurate.

FQDN Firewall Address Object simply looks up the FQDN and substitutes the IPs as the object. Any time a client gets a different IP back it will fall outside the policy. Any time the client tries to go to one of the other many addresses owned by servers used by facebook or youtube, that don't fall within the IPs resolved by www.facebook.com, it will fall outside the policy. FQDN address objects are NOT intended as a webfilter and you cannot specify *.facebook.com as an FQDN Address object. How do you do an nslookup for that? Answer is you can't. 

FQDN address objects are great for permitting or denying access to dynamic DNS IP's or servers that change IP from time to time. For example permit RDP to rdpserver.mycompany.com or VPN from remoteoffice.dyndns.com. They are NOT for complex websites.  Fortinet provides three methods to do that correctly:  1. URL Filter  2. Webfilter (catgories)  3. Application Control. 

I think I'll just need to re-evaluate the approach I'm taking, and look to focus more on Application Control & Web Filtering rather than static Policy rules. While the problem isn't resolved, hopefully this thread can at least help others that come across the same issue.

Cheers.

[sw2090]

Just 4 Info: Fortinet TAC told me upon a ticket that you cannot use wildcards in webfilter rating overrides so I could imagine you cannot also use them in objects.

Also keep in mind: if you manage your FGT with a FMG there is a known bug in FMG v5.4 that affects wildcard url filter entries in their order!

[emnoc]

FWIW

diag debug flow

Would be helpful in gathering the reason(s) as to why your policies are not working. The output or lack of output, will provides clues that could lead you to the correct "corrective action(s)"

[Adrian_Buckley_FTNT]

There's a couple things to remember about FQDNs.

1) Whatever you enter is EXACTLY what gets sent to DNS for resolution

    * is a supported DNS character but most domains are not setup to resolve it

2) Geographic DNS - if used, the website will give different IPs to a DNS server based on it's geography

3) Round Robin DNS - if used, the IPs will change periodically

FQDNs are a shortcut way to enter an IP address.  Firewall policy's operate on IPs after all.  In the case of an FQDN the FortiGate will send the entry to DNS for resolution.  The response will be cached until it expires.  This value is determined by the DNS entry itself.

Take Google as an example.  They use Geographic and round robin DNS.

So, unless you lock out users to using only a single DNS server, they may get different IPs depending on which DNS server is used in order to resolve their query.   If the IP that is used to access is not included in the firewall policy, no match.

Also, Googles DNS record is valid for 5 minutes.  This means the FortiGate will recheck the FQDN every 5 minutes.  Now even if you do lock users to a single DNS server, unless the FortiGate is 100% in sync with the DNS server (ie: it query's the FQDN exactly at the point the record is updated) then there will be a certain amount of time that the 2 are not in sync and the result of the user queries will not match what the FortiGate has.

Also, since google is not setup to resolve *.google.com you would need to setup every single google domain and subdomain as FQDNs and lock users to using a single DNS server .... even then you would not get coverage that could compare to Application control or web filtering.