Firewall Logs

overspray

I keep getting a bunch of entries (from two a second to one every few seconds) in the WAN firewall log from an IP 10.x.x.x to 255.255.255.255:68

I realize that I can't have the "block RFC1918" and "block bogon networks" enabled for the WAN interface without them being logged, but if I uncheck them won't they be blocked by default? Currently, I only have a pass rule for OpenVPN and I temporarily put in a rule for incoming to 255.255.255.255 that isn't logged just to be safe.

I can deal with the extra log entries if need be to make everything more secure, but if everything is explicitly denied unless specifically allowed, wouldn't I still be just as secure this way? Am I missing something?

Sorry if this has been covered already, but I couldn't find it in the forums.

Thanks,
Jim

Cino

Are you on a cable modem? I bet you are… Its dhcp arps or somthing from your provider

easy fix

Create an alias and put all the RFC1918 ranges in it:
10.0.0.0/8
172.16.0.0/12
192.168.0/16

Make sure you have block RFC1918 unchecked under the WAN tab
Then create a rule to block all traffic using the alias as your source.

It will do the same thing as Block RFC1918 but wont log it in your firewall log...

overspray

Yes I am on a cable modem. I didn't realize that it was from my provider.

Entered the firewall rule. Everything is fine now. Now the firewall log is actually useful!

Thanks for the help!

Jim

Cino

your welcome ;D

horost

I have the same issue (running nanobsd 1.2.3) with my cable ISP, except the source address is UDP port 67 on one of their public IP addresses. They occur every five seconds for the OPT1 interface, so it really creates a lot of useless firewall entries.

What is the most graceful way to handle this? Should I just add a block rule for UDP traffic on port 67 for that specific IP address?

jimp

Just add a block rule that matches the traffic and is not set to log.

Because that is a WAN connection, you should never need incoming DHCP traffic there. Anything you do need is initiated from the firewall itself and will work because there will be an existing state for the traffic.

horost

Thanks jimp.

That looks good, but now it appears that I have the same issue with IGMP traffic from the same public IP to destination 224.0.0.1. :P Looks like I'll have to do something similar there to cut down on the noise in my firewall log.

BTW, I enjoyed the book. I bought it in March and was able to read the entire thing when I had jury duty. :)