Bug #13209
openParsing Filter log by pfBlockerNG creates IP Block log with Source/Destination mixed up or wrong Direcion
0%
Description
For example
May 20 16:23:12,1653043863, ixl3 ,WAN,block,4,6,TCP-S, 179.x.x.x , 77.y.y.y ,37221,81, out ,BE,pfB_PRI1_v4,77.y.y.0/21,BE_v4,Unknown,Unknown,Unknown,+
where
- 179.x.x.x is external IP
- 77.y.y.y is his local IP
- ixl3 is his main WAN port
so for traffic from 179.x.x.x to 77.y.y.y on WAN the direction must be IN but not OUT
I think parsing function pfb_daemon_filterlog from https://gist.githubusercontent.com/BBcan177/7cb8635199446866d511b97166d65296/raw/ mixes up Source and Destination IPs or inverts Direction.
Updated by Azamat Khakimyanov over 2 years ago
Customer created this topic on forum: https://forum.netgate.com/topic/172322/ip_block-log-entry-query-direction
Updated by Djerk Geurts over 2 years ago
Happy to provide more detail if needed.
Regarding the interfaces, we actually have 4 wan interfaces and all internal connections are dual attached using FRR BGP routed connections.
We see log entries for firewall destined traffic reported correctly. But traffic received on a s
wan interface routed to the DMZ is reported as out-bound traffic. Thus pfblockerNG provides (ASN, object etc) details on the (DMZ) destination rather than source of the logged traffic.
Updated by Djerk Geurts over 2 years ago
Azamat Khakimyanov wrote:
I think parsing function pfb_daemon_filterlog from https://gist.githubusercontent.com/BBcan177/7cb8635199446866d511b97166d65296/raw/ mixes up Source and Destination IPs or inverts Direction.
Could this be related to our 4 WAN interface config? We're using a gateway group, and due to GBP routing DMZ hosts aren't seen as directly connected to the firewall, aka there's a gateway required to reach them.