Hello everyone!
Giving the following scenario:
I have two policies with the same source and destination "all", but each policy has a different Webfilter profile.
If a request doesn't match any url in the webfilter for the first policy, will this request be denied or the second policy will be evaluated?
I ask that because we are migrating policies from another firewall vendor to Fortigate and in that other vendor, there is some similares policy rules, with exact same source and destination "any", but with distincts URL Categories and all policies are evaluated until a match or the request is denied just on the implicit deny.
As I can see, the Fortigate will block the request in the first policy if no match in the Webfilter and will not evaluate the second policy, because it already have matched the first policy by source and destination address. Is that correct?
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
it will match the first policy due to the destination and if it doesn't match the webfilter profile it will be blocked (or whatever is configured in the webfilter profile)
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Hey Gui,
sorry for only now getting back to you.
If you change the firewall mode to policy-based, that can significantly screw up your existing policies, so I would recommend against doing that if the FortiGate is in production. It would essentially be a redesign of all policies and applicable security profiles, not something you can test for five minutes and easily reverse.
If you are looking for your FortiGate to work like that in principle (traffic policies, and then separate security policies to apply webfilter/other UTM more granularly), I would suggest either a VDOM on your FortiGate, or a lab/VM/... FortiGate to test the options thoroughly and get familiar with policy-based mode, and only then make a decision whether to reconfigure your production FortiGate to work in policy-based mode.
Hey Gui,
sorry for only now getting back to you.
If you change the firewall mode to policy-based, that can significantly screw up your existing policies, so I would recommend against doing that if the FortiGate is in production. It would essentially be a redesign of all policies and applicable security profiles, not something you can test for five minutes and easily reverse.
If you are looking for your FortiGate to work like that in principle (traffic policies, and then separate security policies to apply webfilter/other UTM more granularly), I would suggest either a VDOM on your FortiGate, or a lab/VM/... FortiGate to test the options thoroughly and get familiar with policy-based mode, and only then make a decision whether to reconfigure your production FortiGate to work in policy-based mode.
If a request does not match any URL in the webfilter profile specified in the first policy, the request will be evaluated based on the rules of that specific policy. If there is no explicit deny rule in the first policy, the default action would likely be to allow the traffic. In this case, the second policy may not be evaluated because the request has already been matched by the source and destination addresses of the first policy.
I still think those current Palo Alto policies are not exactly the same not only the webfilter profiles, like applications and services, etc. And only one of them matches and be executed.
Toshi
You are right. In Palo Alto there are differents Application (not services). But, even this different applications use the same ports (80 and 443). But, if the "application" in Palo Alto doesn't gives only the port used by application, but the ports and dest address, I think this is the case.
But in Fortigate we doesn't have the option Application same as PA.
An important point: This policies is not for users traffic/internet access, but is related to some devices accessing external resources to do software updates, dns sync, etc. There are a few static URLs allow list (with some wildcards) like for exemple *.windowsupdate.microsoft.com. So I think that in this case, if I copy the urls in the webfilter and create fqdn objects to add as destinations it will works. What do you think?
Created on 07-07-2023 08:42 AM Edited on 07-07-2023 08:43 AM
Last time, long time ago, when I tested PA-220 I didn't test that part of behavior. I guess I have to learn more about PAN.
To me, most of those requirements can be done by one policy in a way, and it would apply to your case. When the process hit that policy, it just look for the first match in all addresses and profiles. So should work fine.
Toshi
Hello Gui,
Traffic is matching only single policy. For example firewall policy A and webfilter profile A1 and firewall policy B and webfilter profile B1. Traffic will hit either policy A or policy B, but not both. Therefore either webfilter profile A1 will applied or webfilter profile B1, but not both.
To clarify:
- policies are matched on source interface, destination interface, source address, destination address and service ONLY. They are not matched on any UTM profile.
That is, if the traffic is matched on the first policy, the second one will never be evaluated.
This is different from PA where the web filter is part of the match criteria.
Regarding policy UTM mode, have a close look at the cited article. It forces you to enable Central NAT, among other stuff. This alone requires reworking your NAT policies which will not happen live on a production FGT.
In the context of network security a policy with a web filter and a destination set to any typiclly means that the policy will apply
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1710 | |
1093 | |
752 | |
447 | |
231 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.