Skip to main content
Mikelar
Mikelar
New Member
December 4, 2014
Question

FQDN Objects & IPv4 Policy

  • December 4, 2014
  • 5 replies
  • 106095 views

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.

      • 5 replies

      Dave_Hall
      Dave_Hall
      New Member
      December 4, 2014

      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
      MikelarAuthor
      New Member
      December 5, 2014

      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
      Dave_Hall
      New Member
      December 5, 2014

      @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."

      emnoc
      emnoc
      New Member
      December 5, 2014

      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
      Staff
      Adrian_Buckley_FTNT
      Staff
      December 9, 2014

      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.

      Mikelar
      MikelarAuthor
      New Member
      December 10, 2014

      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
      AtiT
      New Member
      December 10, 2014

      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
      Dave_Berger
      New Member
      October 27, 2015

      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
      nothingel
      New Member
      October 28, 2015

      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
      Dave_Berger
      New Member
      October 28, 2015

      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
      nothingel
      New Member
      October 28, 2015

      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.

       

       

      Terms & ConditionsAccessibility statement