SG-5100 Firewall logs dissapearing
-
Hmm, weird. Almost looks like what you might see with a very low log rotation timer set. Except you can't set that in 2.4.5p1, that's a new feature in 2.5.
Check the actual log file if it;s still happening: /var/log/filter.log
See if it's actually removeing the log data or just filtering the GUI view.Steve
-
@stephenw10
Yes, strange indeed...Yeah checking the log file via Shell only shows the last several events generated within the last couple of hours. Currently nothing in the log with a timestamp before Jan 25 08:43:06.
-
Hmm, the log files in 2.4.5p1 are circular with a fixed size, the default being 512K. That is usually ~4000 log lines. It's not rotated based on time/date.
Do you have any other packages that may be interfering with that?
Steve
-
@stephenw10 said in SG-5100 Firewall logs dissapearing:
Do you have any other packages that may be interfering with that?
Steve
I wouldn't even know how to begin to answer that question... I'm pretty new to pfsense...
However, as I mentioned earlier, this problem seemed to start after I installed the 'softflowd' package. My intention was to send NetFlow data to a separate server running ntop. I was unable to get this working so I aborted the effort and removed the package..
Here are all the packages I have installed:
-
Mmm, I can't really imagine any package the might either.
So to be clear the actual log file is only a few bytes in size?
As I say it should be 512KB. That could be the timespan you're seeing if it was just the gui filtering logs.
Steve
-
If the entries cannot be parsed, they are not shown/counted, so it's possible there is data in the log file but it's not what the system expected.
What is in the log file at the time? (
clog /var/log/filter.log
) -
I guess something could be filling the log file with unreadable data that clog doesn't show. The filesize should still be 512K though if that was the case.
-
Thanks for the help guys. Really appreciate it!!
So it appears the log file is not empty at all:
-rw------- 1 root wheel 511488 Jan 26 12:07 filter.log
This is confirmed with command: clog /var/log/filter.log
This is the first 7 lines of the file which has 3347 lines.
22,ff02::16,HBH,RTALERT,0x0000,PADN, Jan 26 09:48:11 pfSense filterlog: 64,,,11000,igb0,match,block,in,6,0xe0,0x00000,1,Options,0,136,fe80::29e:1eff:fe59:822,ff02::16,HBH,RTALERT,0x0000,PADN, Jan 26 09:48:14 pfSense filterlog: 64,,,11000,igb0,match,block,in,6,0xe0,0x00000,1,Options,0,136,fe80::29e:1eff:fe59:822,ff02::16,HBH,RTALERT,0x0000,PADN, Jan 26 09:48:18 pfSense filterlog: 64,,,11000,igb0,match,block,in,6,0xe0,0x00000,1,Options,0,136,fe80::29e:1eff:fe59:822,ff02::16,HBH,RTALERT,0x0000,PADN, Jan 26 09:48:22 pfSense filterlog: 64,,,11000,igb0,match,block,in,6,0xe0,0x00000,1,Options,0,136,fe80::29e:1eff:fe59:822,ff02::16,HBH,RTALERT,0x0000,PADN, Jan 26 09:48:24 pfSense filterlog: 64,,,11000,igb0,match,block,in,6,0xe0,0x00000,1,Options,0,136,fe80::29e:1eff:fe59:822,ff02::16,HBH,RTALERT,0x0000,PADN, Jan 26 09:48:25 pfSense filterlog: 64,,,11000,igb0,match,block,in,6,0xe0,0x00000,1,Options,0,136,fe80::29e:1eff:fe59:822,ff02::16,HBH,RTALERT,0x0000,PADN,
However when I try this command: clog /var/log/filter.log | filterparser.php
It only shows one line, which is the same as the GUI:
Jan 26 11:54:59 block igb0 UDP 80.82.65.90:45735 73.24.XXX.XXX:123
-
Mmm, that's fun. It is just the logs rotating pull out the old log lines at least.
So multicast IPv6. Is igb0 your WAN?
Do you have 'Log packets blocked by 'Block Bogon Networks' rules' unset in the log settings?
Steve
-
@stephenw10
Yes, igb0 is the WAN.No, Block Bogons is checked.
Also, I had 'GUI Log Entries' set to 2000 originally but changed to 500. Didn't seem to help..
-
Hello!
Your filter.log lines dont look like mine...the RTALERT and PADN looks odd...
Found this in the way-back-machine...
https://forum.netgate.com/topic/102426/my-firewall-log-is-getting-trimmed
If those lines are being ignored and you are getting a lot of them, they could be flushing out the "valid" lines.
Maybe try bumping up your log file size in Status -> System Logs -> Settings and see if you are able to retain more of the important log lines.
John
-
That is almost certainly the case. The log parser is dropping/ignoring those lines, and there aren't many/any others left to show.
Find whatever is causing those log messages and fix it, and then the log will be more useful.
-
Yes, though that may not be possible if it's something WAN side.
You could probably also add a custom block rule on WAN to catch that and not log it so it doesn't fill the log.
Steve
-
Well I think that was it!
I disabled 'Log packets blocked by Block Bogon Networks rules' at 14:05 today. I just checked the filter log file and the last RTALERT and PADN entry occurred exactly at 14:06:01. Nothing but valid firewall events after that... Up until that point it was logging about 230 of those offending messages per hour.
The funny thing is, I've always had that Bogon logging option enabled and never had a problem until now.. My ISP is Comcast and like the mention in bug report #3494, Comcast appears to send ICMP6 Multicast Listener Report messages out on their system which get flagged as Bogon traffic by pfSense. I guess Comcast must have made some changes recently that increased the flow of this type of traffic...
Anyway, glad we got to the bottom of it. Thanks again for all the help! No way I could have figured this out on my own...