Hot!FQDN Objects & IPv4 Policy

Page: 12 > Showing page 1 of 2
Author
Mikelar
Bronze Member
  • Total Posts : 33
  • Scores: 0
  • Reward points: 0
  • Joined: 2014/01/30 21:52:12
  • Status: offline
2014/12/03 20:06:01 (permalink)
0

FQDN Objects & IPv4 Policy

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:
  • Name: LogMeIn_1
  • Type: FQDN
  • FQDN: *.logmein.com
  • Interface: any

IPv4 Policy below:
  • From: lan
  • To: wan1
  • Source: all
  • Destination: LogMeIn_1
  • Schedule: always
  • Service: HTTP, HTTPS
  • Action: Accept
  • NAT: enable
 
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.
#1

26 Replies Related Threads

    Dave Hall
    Expert Member
    • Total Posts : 1246
    • Scores: 118
    • Reward points: 0
    • Joined: 2012/05/11 07:55:58
    • Location: Canada
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2014/12/03 23:57:46 (permalink)
    0
    Mikelar
    I'm using the address object below:
    • FQDN: *.logmein.com

     
    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.

    FMG-VM64/FortiAnalyzer-VM/4.0/5.0/5.2/5.4 (FWF40C/FW92D/FGT200B/FGT200D) / FAP220B/221C
    #2
    Mikelar
    Bronze Member
    • Total Posts : 33
    • Scores: 0
    • Reward points: 0
    • Joined: 2014/01/30 21:52:12
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2014/12/04 22:14:12 (permalink)
    0
    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
    • Web Filtering disabled
    • Application Control disabled
    • IPv4 Policy as shown in attachment here.
    • Forward Traffic Log as shown in attachment here.
    • Result: LogMeIn blocked
     
    Test 1
    Policy allowing only HTTP/S traffic to all destinations
    • Web Filtering disabled
    • Application Control enabled as shown here.
    • IPv4 Policy as shown here.
    • Forward Traffic Log as shown here.
    • Result: LogMeIn working
     
    Test 2
    Policy allowing all traffic to FQDN logmein.com
    • Web Filtering disabled
    • Application Control enabled as shown here.
    • IPv4 Policy as shown here.
    • Forward Traffic Log as shown here.
    • Result: LogMeIn blocked
    post edited by Mikelar - 2014/12/04 22:27:28
    #3
    emnoc
    Expert Member
    • Total Posts : 4988
    • Scores: 306
    • Reward points: 0
    • Joined: 2008/03/20 13:30:33
    • Location: AUSTIN TX AREA
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2014/12/05 01:06:03 (permalink)
    0
    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)"

    PCNSE,  NSE , Forcepoint ,  StrongSwan Specialist
    #4
    Dave Hall
    Expert Member
    • Total Posts : 1246
    • Scores: 118
    • Reward points: 0
    • Joined: 2012/05/11 07:55:58
    • Location: Canada
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2014/12/05 10:34:15 (permalink)
    0
    @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."

    Attached Image(s)


    FMG-VM64/FortiAnalyzer-VM/4.0/5.0/5.2/5.4 (FWF40C/FW92D/FGT200B/FGT200D) / FAP220B/221C
    #5
    Mikelar
    Bronze Member
    • Total Posts : 33
    • Scores: 0
    • Reward points: 0
    • Joined: 2014/01/30 21:52:12
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2014/12/07 19:53:43 (permalink)
    0
    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
    • 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.
     
    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
    • 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
     
    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.
     
    #6
    Dave Hall
    Expert Member
    • Total Posts : 1246
    • Scores: 118
    • Reward points: 0
    • Joined: 2012/05/11 07:55:58
    • Location: Canada
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2014/12/07 21:10:29 (permalink)
    0
    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.

    FMG-VM64/FortiAnalyzer-VM/4.0/5.0/5.2/5.4 (FWF40C/FW92D/FGT200B/FGT200D) / FAP220B/221C
    #7
    Mikelar
    Bronze Member
    • Total Posts : 33
    • Scores: 0
    • Reward points: 0
    • Joined: 2014/01/30 21:52:12
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2014/12/07 23:49:49 (permalink)
    0
    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.
     
    #8
    Adrian Buckley_FTNT
    Gold Member
    • Total Posts : 261
    • Scores: 6
    • Reward points: 0
    • Joined: 2008/01/09 14:14:22
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2014/12/09 07:24:04 (permalink)
    0
    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.
    post edited by Adrian Buckley_FTNT - 2014/12/09 07:25:58
    #9
    Mikelar
    Bronze Member
    • Total Posts : 33
    • Scores: 0
    • Reward points: 0
    • Joined: 2014/01/30 21:52:12
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2014/12/09 17:44:47 (permalink)
    0
    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.
    #10
    AtiT
    Gold Member
    • Total Posts : 440
    • Scores: 32
    • Reward points: 0
    • Joined: 2012/04/18 12:13:27
    • Location: Prague / Czech Republic
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2014/12/10 01:46:44 (permalink)
    0
    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)

    AtiT
    --------------------
    NSE 8, CCNP R+S
    #11
    Dave Berger
    Bronze Member
    • Total Posts : 21
    • Scores: 4
    • Reward points: 0
    • Joined: 2012/03/23 02:25:15
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2015/10/27 01:27:21 (permalink)
    0
    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.
    #12
    nothingel
    Silver Member
    • Total Posts : 76
    • Scores: 4
    • Reward points: 0
    • Joined: 2010/07/01 14:03:01
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2015/10/27 23:16:00 (permalink)
    0
    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
     
    #13
    Dave Berger
    Bronze Member
    • Total Posts : 21
    • Scores: 4
    • Reward points: 0
    • Joined: 2012/03/23 02:25:15
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2015/10/28 00:07:57 (permalink)
    0
    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.
    #14
    nothingel
    Silver Member
    • Total Posts : 76
    • Scores: 4
    • Reward points: 0
    • Joined: 2010/07/01 14:03:01
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2015/10/28 11:17:11 (permalink)
    0
    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.
     
     
    #15
    Dave Berger
    Bronze Member
    • Total Posts : 21
    • Scores: 4
    • Reward points: 0
    • Joined: 2012/03/23 02:25:15
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2015/10/28 23:59:50 (permalink)
    0
    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.
    #16
    mok
    New Member
    • Total Posts : 7
    • Scores: 0
    • Reward points: 0
    • Joined: 2016/01/28 06:50:01
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2016/02/18 06:53:44 (permalink)
    0
    The use of wildcard FQDN addresses within firewall policies is currently  STILL not supported on 5.4 That is very annoying !!!!
    #17
    Erwin
    New Member
    • Total Posts : 1
    • Scores: 0
    • Reward points: 0
    • Joined: 2016/07/08 05:17:53
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2016/07/11 13:19:29 (permalink)
    0
    mok
    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.


    #18
    mok
    New Member
    • Total Posts : 7
    • Scores: 0
    • Reward points: 0
    • Joined: 2016/01/28 06:50:01
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2016/07/12 04:45:10 (permalink)
    0
    Thanks for feedback Erwin, I'm really disappointed for that! For me the use of Walled Garden is impractical too.
    #19
    MikePruett
    Platinum Member
    • Total Posts : 676
    • Scores: 15
    • Reward points: 0
    • Joined: 2014/01/08 19:39:40
    • Location: Montgomery, Al
    • Status: offline
    Re: FQDN Objects & IPv4 Policy 2016/07/18 19:06:23 (permalink)
    0
    Yeah wildcard FQDN on 5.4.1 is no bueno so far. Major bummer too.

    Mike Pruett
    Fortinet GURU
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2018 APG vNext Commercial Version 5.5