- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Firewall action Allow in policy 0?
Hi all,
Recently I 've update my Fortigate 600E to 7.0.12 and I have Fortianalyzer 400E with v7.2.3. I've observed that I have a lot of Firewall "Allow action" matching policy 0. The traffic is not passing (there are no received packets) but it's confusing for me when I study logs. I've read the release notes and I don't have find a bug talking about this.
Why I see Accept action when the policy ID is 0? Thanks
- Labels:
-
FortiAnalyzer
-
FortiGate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
more details needed - check the log details (port,IPs,etc). An explanation is available here:
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Local-traffic-logs-and-policy-ID-0/ta-p/19...
- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @fortimaster,
Can you confirm if those logs are local in traffics which means the traffic is destined to the FortiGate itself?
Policy ID 0 is implicit policy for any automatically added policy on FortiGate. Policy ID 0 is used to process self-originating packets, packets that hairpin through the FortiGate, or packets that don't match any other policies but are reported through logging anyway (implicit deny). Please refer to https://community.fortinet.com/t5/FortiGate/FortiGate-log-information-traffic-log-with-firewall-poli...
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your replys. It's not local traffic, It's normal traffic from computers, for example, that not matches any firewall policy and finally it matches policy 0. In some cases I can see the deny action and in others not... I attach you an image. I can see this example in "logs" forward traffic (not in local traffic).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have an FQDN configured for this traffic in the policy?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @fortimaster,
Are you getting the same logs on the FortiGate and FortiAnalyzer? Is it possible to provide more log details?
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you share the log in raw format as below for one of these instance to get better understanding . You can get the raw log from Fortianalyzer after applying filter for action accept and policy id 0.
date=2020-12-01 time=01:00:01 devname="lab-FGT01" devid="FGT1KD0000000001" logid="0001000014" type="traffic" subtype="local" level="notice" vd="root" eventtime=1606780801000000000 tz="+0100" srcip=10.0.0.2 srcport=38793 srcintf="port1" srcintfrole="lan" dstip=10.0.0.1 dstport=520 dstintf="unknown0" dstintfrole="undefined" sessionid=1000000001 proto=17 action="accept" policyid=0 policytype="local-in-policy" service="udp/520" dstcountry="Reserved" srccountry="Reserved" trandisp="noop" app="RIP" duration=180 sentbyte=52 rcvdbyte=0 sentpkt=1 rcvdpkt=0 appcat="unscanned"
Implicit-deny logs (which share policy ID 0), will be type="traffic" subtype="forward" instead.
Suraj
- Have you found a solution? Then give your helper a "Kudos" and mark the solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your help.
The problem comes from Fortigate. I can see that mistake in the memory logs. It matches policy 0, I don't have a policy with FQDN that causes the mistake. I can see some deny examples like that
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm quite confident the "problem" is not a "real problem" , but you see it as such because there is no good explanation provided (yet) for this behaviour. And you will probably not receive a good explanation online, without sharing your config and complete logs. I would advise you to open a case with TAC (providing config and full logs) to provide you with a good explanation.
- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks.
