had an issue recently where the choice of a policy made totally no sense for certain traffic.
i use diagnose debug flow and see pretty much no other useful information the the choice of policy ID.
is there something else i can do? it would be great if there is some extra option to actually list why the fortigate feels that traffic matches a certain policy.
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.
Nope, the diag debug flow is the best thing for the fortigate fwpolicy-id diagnostic. It will show you what was matched, policyid, route lookup, SNAT/DNAT, any other utm actions,etc......
It's probably the best thing out on the market outside the checkpoint fw cmd or cisoc asa packet-tracer.
So what problem are you actually seeing or the expect behavior?
PCNSE
NSE
StrongSwan
in this case it was DNS traffic from an unauthenticated source hitting a policy with group authentication (FSSO) and being allowed there, it took me a while to remember this is default behaviour.
anyone have a good public source for this btw? i can only find it in the NSE4 training material. the authentication admin guide only states you need to setup a separate DNS allow policy before any authentication policies.
so when i first noticed it i started investigating the fact if the IP wasn't somehow authenticated, why did the fortitgate believe it belonged to that group? diag debug flow is helpful in pointing out results, but not why they are made. i would love to see something that compares the packet to the policy and comes out with source: match, destination: match, authentication group: failed, but DNS so match.
would have saved quite some searching and having doubts about FSSO working correctly again.
and that is just one example, had something similar in the past where the policy choice didn't make sense until i noticed the service config was messed up. again if diag debug flow had shown a match on the service i would have been able to focus on that much quicker.
anyway, in the end both were solved, but i had hoped for a hidden extra flag
I think it is just one of those uniquely Fortinet things for "this is just how it works" lol.
I pulled my hair out a good bit on a deployment before I realized it.
Mike Pruett
Hi, Why you dont try diag sys session list with filter expressions?
example:
diag sys session filter src 192.168.1.5 diag sys session list the output will show to you the policy id that the traffic math
does it help me in understanding why the traffic matches that policy id? i believe that session table doesn't show anything more.
The session table will show the policy-id when it's established. We restart the application and or traffic and monitor the session table but the diag debug flow is the best thing on planet earth imho.
PCNSE
NSE
StrongSwan
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 |
---|---|
1688 | |
1087 | |
752 | |
446 | |
227 |
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.