Policy Error in Fortigate 100D

[cjefferson]

Hello, 

I have in my company a Fortigate 100D with FortiOS 4.0 MR3 Patch 12.

A few weeks ago, some users began to show ceritificado error in Office365 online. Thus, there is a loss of connection to Lync and Outlook.

I switched the order of the rule (Scenario 1) which solved this problem. But now the firewall is not blocking the access of users. Restricted sites are being accessed.

Has anyone had a similar problem?

Scenario 1: Status error: Lync and Outlook running. Blocking rules of users failing.

Order rules:

Rule: LAN to WEB ID: 10 Source: Full Access Destination: All

ID: 47 Rule: LAN to WEB Source: Internal Network Destination: All

Scenario 2: Status error: Lync and Outlook failing. Blocking rules of users working.

Order rules:

ID: 47 Rule: LAN to WEB Source: Full Access Destination: All

ID: 10 Rule: LAN to WEB Source: Internal Network Destination: All

Thank you for your help.

[Dave_Hall]

Hi Carlos.

Welcome to the forums.

Check to see if the error is reporting the cert does not match, which likely may mean you have deep inspection enabled, but the client computers do not have the Fortigate certificate installed. 

But we need more information on the issue, including the exact error and maybe a screenshot showing on your firewall policies (mainly policy rule #10 and rule #47). 

Firewall policy rules are execute from top-to-bottom, so changing the rule order could definitely effect your network/internet access. 

Since your policy rules (10 & 47) indicated they are web-based rules for controlling web access, you will want to troubleshooting the problem in that direction, so questions like:

[ul]

does problem effect all computers or just some

does the problem effect all sites or just some sites?

all http sites or just https sites?

if https sites, is the time/date/timerzone correct on the client computers and the Fortigate as well?

is the error message just about an invalid cert (showing the Fortigate's cert instead of the real site cert)

etc[/ul]

[pushpendra11]

Hi

As i see in your post Scenario 1 : policy ID 10 is equivalent to policy id 47 in scenario 2

also ,can you please update the policy details, like allowed ports? is there any UTM's like web filtering or Application control applied for restricting the user access ?

And after facing the issue you reordered the policy ,as i understand policy id 10 has been moved policy id 47 is it correct ? 

Regards, Pushpendra11

[trauthor]

There are multiple posts in this forum related to VIP policy compromising security.  I have opened cases with FortiNet both for this issue and an additional issue.  I have also alerted appropriate parties.  To FortiNet's credit, they are working quickly to address this.  I have not yet seen an official public statement from FortiNet.  Please refer to the below correspondence to see if it pertains to your situation.  Thank you.

==========

Fw: FortiGate Security "Loophole" and Severe Bug

Two issues were discovered during FortiGate firewall product tests, the first a documentation issue which FortiNet has confirmed affects FortiOS 5.0.x and 5.2.x and the second a bug which affects any FortiGate "D" series in combination with FortiOS 5.0.10 (the FIPS 140 version; it is unknown whether other combinations of FortiOS and FortiGate are affected.)

1)  FortiGate Deny All rules do not deny all traffic.  What is documented:  "VIP rules" take precedence over "regular rules."  However, until two days ago (6/15/2015) after it was recently brought to their attention this was mentioned only briefly in a technical note and not in any of their standard documentation (the FortiOS handbook, admin guide, etc.)  It remains inexplicit that "VIP rules" also take precedence over "Deny All" rules.

- Here's the link to the technical note (taken from the support case):  http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD33338

- Here's the link to the updated handbook, published 6/15/2015 (see page 956, "Exception to policy order (VIPs):")  http://docs.fortinet.com/d/fortigate-fortios-handbook-the-complete-guide 

The scenario documented in the stem support case is given below.  Rules appear in the same order they would after issuing the commands "config firewall policy" and "get."

=====

config firewall policy

edit 1

set srcintf "wan1"

set srcaddr "outside_blacklist"

set dstintf "dmz"

set dstaddr "all"

set action deny

set schedule "always"

set service "ALL"

set logtraffic all

next

edit 2

set srcintf "wan1"

set srcaddr "all"

set dstintf "dmz"

set dstaddr "nat_inside"

set action accept

set schedule "always"

set service "ALL"

set logtraffic all

next

end

=====

In the above example, "outside_blacklist" is a group of outside addresses and "nat_inside" is a VIP on the firewall.  As depicted, traffic will not follow the usual order of precedence.  Any traffic destined for "nat_inside" will ignore the Deny All in Rule 1 but match the Accept in Rule 2.  Below is the fix suggested by a FortiNet support engineer.

=====

config firewall policy

edit 1

set srcintf "wan1"

set srcaddr "outside_blacklist"

set dstintf "dmz"

set dstaddr "nat_inside"

set action deny

set schedule "always"

set service "ALL"

set logtraffic all

next

edit 2

set srcintf "wan1"

set srcaddr "all"

set dstintf "dmz"

set dstaddr "nat_inside"

set action accept

set schedule "always"

set service "ALL"

set logtraffic all

next

end

=====

Shown above, the change replaces the Deny All in Rule 1 with Deny "nat_inside."  This in effect restores the order of precedence.  (For an explanation, see the new section "Exception to policy order (VIPs)" in the handbook.  For the alternative fix, "match-vip," see the technical note.)  To summarize, FortiGate "VIP rules" are matched before "regular rules."  Most significantly, "VIP rules" are matched before "Deny All" rules.

The potential for a security "loophole" as described in the above case is compounded by:

a) a reasonable (until two days ago) expectation that a Deny or Deny All policy always denies blacklisted traffic in order of precedence; and

b) typical industry practice that only denied traffic gets logged.

Given these factors, a configuration error which would allow blacklisted traffic to enter a network undetected via an Accept rule is not unlikely.  [...]

2)  The secondary unit in a FortiGate "D" series active/passive cluster bricks (i.e., fails closed and must be re-imaged) after the first couple FIPS self-tests under certain conditions, two of them being:  when it can't contact the master; when it is given the master's configuration file.  Anyone with "D" series units will not be able to maintain an active/passive cluster in FIPS-CC mode.  An "emergency" code fix of FortiOS 5.0.10 is underway which will be released as 5.0.13.  We have been assured by FortiNet this will not affect the FIPS 140 certification of FortiOS.