Firewall log
-
And I guess you have more restrictive rules on LAN, not the default pass all rule, and that you are not using pfSense for DHCP on LAN. And that would be why those packets are being blocked.
(Normally with the default pass all on LAN that broadcast traffic would pass through the firewall and the network stack would try to deliver it to whatever might or might not be waiting on port 67/68) -
And I guess you have more restrictive rules on LAN, not the default pass all rule, and that you are not using pfSense for DHCP on LAN. And that would be why those packets are being blocked.
(Normally with the default pass all on LAN that broadcast traffic would pass through the firewall and the network stack would try to deliver it to whatever might or might not be waiting on port 67/68)Close - the default LAN rule specifies source of "LAN net", so the 0.0.0.0-sourced DHCP requests wouldn't match. Otherwise correct. We automatically add rules to allow that in the background when the DHCP server or relay is enabled. So probably a default config minus DHCP server.
Just adding a block rule on LAN for destination 255.255.255.255 with no logging enabled would suffice.
-
@cmb:
And I guess you have more restrictive rules on LAN, not the default pass all rule, and that you are not using pfSense for DHCP on LAN. And that would be why those packets are being blocked.
(Normally with the default pass all on LAN that broadcast traffic would pass through the firewall and the network stack would try to deliver it to whatever might or might not be waiting on port 67/68)Close - the default LAN rule specifies source of "LAN net", so the 0.0.0.0-sourced DHCP requests wouldn't match. Otherwise correct. We automatically add rules to allow that in the background when the DHCP server or relay is enabled. So probably a default config minus DHCP server.
Just adding a block rule on LAN for destination 255.255.255.255 with no logging enabled would suffice.
Im running a pretty much default setup on pfsense, except that I have added static LAN IPs for all devices on my LAN ( DHCP Static Mappings ), and I have enabled the option " Deny unknown clients" and I have also disabled the DHCP server on the LAN interface.
Is there any way to discover the MAC adress of the device broadcasting for an IP address?
-
Go to Diagnostics - Packet Capture and set the Level of Detail to Full. Then start it, wait a bit and then check it.
-
If you disable the dhcp server, then the dhcp rules that allow would be removed I believe - which then yes the default rule would block such traffic and log it.
So you could create a rule that would trigger on this traffic, and not log it - be it you allow it or block it, etc.. As long a rule would trigger before the default rule that logs you would not see this traffic. But as KOM suggested to find the mac address just sniff. You could setup the sniff to only log udp with port 67 or 68 in it to remove other noise, etc.
-
I started "Packet Capture" 2 days ago and now I get a pfsense notice about "cannot allocate memory"
Apparently, my pfsense harddrive has been filled up with logs, and after looking around a bit see that I have lots of logs in /var/log/
How do i clear all logs?
-
why and the world you think you can run a sniff for 2 days?? You clearly got something NOT getting an IP - so could of prob ran it for 2 minutes and found it.. Or it default to capture 100 packets - why did you change it to unlimited??
-
Im pretty new to pfsense firewall and Im learning by trial and error.
How do i clear my drive from all logs, please?
 -
I guess I have to format the drive and reinstall pfsense.
-
Why? Just ignore the old entries. They are circular and will eventually roll over. pfSense logs cannot fill the disk.
If you want to zero the existing capture file, just start a capture then quickly stop it. It'll clobber what's there.
Or find a way to run this command: rm -f /root/packetcapture.cap
Either in the shell or Diagnostics->Command Prompt.
You might need to reboot depending on what has blown up due to the full disk/memory.
-
I just realized that the error message I was getting wasnt actually due to lack of space on the harddrive, instead it was due to selecting 2 conflicting choices from the settings in the "pfblocker" package.
I made the mistake to include russia in the top spammer tab while also selected russian federation in the europe tab, wich somehow caused a conflict.
After deselecting russian federation in the europe tab the error messages stopped comming.
Thank you anyway for your help.
-
so did you track down your box asking for dhcp?
-
so did you track down your box asking for dhcp?
In a manner of speaking yes, I re-enabled the DHCP server and the security camera started working again.
This surprices me since before I turned DHCP server off I added the camera´s MAC adress to the DHCP Static Mappings and enabled Static ARP, and gave it a static IP.
With my limited understanding of pfsense I assumed that this would allow the camera to communicate with the pfsense firewall even without DHCP.I also turned DHCP off in the camera settings and set it to use a static IP, so I dont understand why the camera is asking the DHCP server for an IP.
My conclusion is that either theres a bug in pfsense, or my securitycamera must have more then one mac address.
If the camera is both wireless and wired, does the each connection type have its own MAC acdress or do they share? -
The static DHCP mapping in pfSense does absolutely nothing if the DHCP server is disabled. It's disabled, as in off.
If you found a bug in anything it's in your camera having a static IP set and still requesting one from DHCP.
Yes, devices with wired and wireless interfaces will almost always have a different MAC address for each interface.
-
mac address are unique - if there is more than 1 interface then there is more than one mac. If you device has wired and wireless interfaces then yes each interface would have its own mac. Other thing since you were seeing requests for dhcp is your device did not actual get set as static - and was asking for dhcp.. which you had turned off.
-
I could swear I have seen wireless access points with the same MAC on ethernet as on the Wi-Fi, but that's a bridge and not really two interfaces… Certainly never a client device like a laptop or camera.
-
I have never seen an access point with same mac – you can not have the same MAC on 2 different interfaces, it breaks everything about what a mac is ;)
A br0 for example or an interface you create by bridging sure it would have one of the macs of one of the interfaces in the bridge.
