Help with Firewall Log
-
So did you go into your daytek and
UNmarking "Broadcast DSL status to LAN" under ->System Maintenance->Management
Yes and unchecking "Broadcast DSL status to router in LAN" did the job, this option has been introduced in version 3.7.6. Draytek mentions New features only in the release notes of the firmware and as I didn't update for long time (there was nothing worth updating IMO) I didn't knew it was there when I updated a week ago. So now I now (again) why you should always stay current with the lastest firmware.
Thanks for your help!!
-
I have another one I could use some help with
Aug 8 16:00 WLAN 0.0.0.0 224.0.0.1
I did a capture with pfsense, but nothing was captured. I tried it with tcpdump and I see some multicasts, but still I don't know what the origin is. Is there someway to find the source?
I have a hunch that it is a Sonos device 16:10:30.388315 xx:xx:xx:xx:75:14 > ff:ff:ff:ff:ff:ff, Unknown Ethertype (0x6970), length 74:
Thanks for any help!
-
yeah 224 is multicast, looks like you already tracked it down via the mac - what is the dest port?
I have turned off default block logging because there is quite a bit of noise when you do that, and created my own block rules above the default that log what I like to see, like tcp syn into my wan. And then any traffic to any pfsense IP on my lan side.
I block most multicast traffic at the switch level since I don't use it there is no reason for it to even get to pfsense interface. While I allow between devices on a specific network/vlan I block it from going to pfsense at the switch ;)
-
Thats a problem there is no port mentioned in pfsense. I tried a tcpdump -i em1 dest host 224.0.0.1 but nothing. So I did a tcpdump i em1 -c 200 and that gave 2 multicasts from the same mac address at a certian time frame that it could correspond with the log in pfSense, but I am not sure.
-
Only TCP and UDP have a notion of a "port". Other IP protocols are free to use ports or not to use them as they choose.
-
what does the firewall log show? It should list the protocol if its a portless one. Does the mac address match up too. you obfuscated the part that would let us look up the hardware maker.
If the firewall blocking it then you would be able to capture it. 224.0.0.1 is the all hosts multicast address.
-
what does the firewall log show? It should list the protocol if its a portless one. Does the mac address match up too. you obfuscated the part that would let us look up the hardware maker.
If the firewall blocking it then you would be able to capture it. 224.0.0.1 is the all hosts multicast address.
You are right (stupid cut-copy-paste) there should have been (see below) in post #27
Aug 9 07:26:14 WLAN 0.0.0.0 224.0.0.1 IGMP
A resolve didn't resolve anything. Well no quite, only that 224.0.0.1 is a all-systems.mcast.net, but that was to be expected. So I can't seem to capture it's source.
07:52:21.097148 xx:xx:xx:xx:13:5e (oui Unknown) > Broadcast, ethertype 802.1Q (0x8100), length 78:
I captured this one with a tcpdump -i em1 ether src xx:xx:xx:xx:13:5e , but the times don't match with the broadcast in the pfSense log.
-
dude look at the mac - why are you hiding it?? And then you can lookup the brand of the device doing it.. From the mac you can find the IP which should tell you what it is for sure..
-
Sorry, maybe I wasn't clear in reply #27 I related "a" broadcast using the mac address in the capture from tcpdump to a Sonos device. The thing I was looking for is way, using pfSense, to proof that the logging in pfSense from source 0.0.0.0 to destination 224.0.0.1 corresponds to the broadcasts I captured with tcpdump (tcpdump makes it easy because there is a mac address in the capture). Thus far I can not, I only have a log from pfSense on 0.0.0.0 to 224.0.0.1 and and tcpdump with a broadcast, but no proof they are related. But maybe I'll have have to accept that the broadcasts from 0.0.0.0 have a high probability to be originated from any of the Sonos devices. If there is a way or if I have overlooked something, please point it out to me, thanks for your time and patience.
-
"Thus far I can not, I only have a log from pfSense on 0.0.0.0 to 224.0.0.1 and and tcpdump with a broadcast, but no proof they are related"
how would the timestamps not be proof that they are same?
While I guess its possible that the timestamp on tcpdump and firewall log could be milli or micro seconds off since firewall might see the packets and block them after tcpdump sees them?? Unless your captures had 1000's and 1000's of packets and blocked packets happening of the same nature I would think seeing a block from 0.0.0.0 to 224.0.0.1 in your firewall log and capture from 0.0.0.0 to 224.0.0.1 would be proof to where its coming from.
Are you saying your seeing hundreds of packets with different macs in your tcpdump and only 1 entry in your firewall log??
Firewall is not going to log the mac because its blocking at layer 3, not layer 2 - it does not care what the mac is.. Its only looking at protocol, IP and evaluating against its rules.. It does not care what the mac was and why the nic moved the traffic up the stack..
-
"Thus far I can not, I only have a log from pfSense on 0.0.0.0 to 224.0.0.1 and and tcpdump with a broadcast, but no proof they are related"
how would the timestamps not be proof that they are same?
While I guess its possible that the timestamp on tcpdump and firewall log could be milli or micro seconds off since firewall might see the packets and block them after tcpdump sees them?? Unless your captures had 1000's and 1000's of packets and blocked packets happening of the same nature I would think seeing a block from 0.0.0.0 to 224.0.0.1 in your firewall log and capture from 0.0.0.0 to 224.0.0.1 would be proof to where its coming from.
Are you saying your seeing hundreds of packets with different macs in your tcpdump and only 1 entry in your firewall log??
Firewall is not going to log the mac because its blocking at layer 3, not layer 2 - it does not care what the mac is.. Its only looking at protocol, IP and evaluating against its rules.. It does not care what the mac was and why the nic moved the traffic up the stack..
Yes the timestamps differ and Yes there were a lot of broadcasts.
According to this guy https://en.community.sonos.com/troubleshooting-228999/issue-with-broadcast-storm-when-i-connect-more-than-one-sonos-device-6207188 multiple Sonos devices are the cause.
In this link a certain Mike V Quotes "The problem is that when you have multiple Sonos components wired to your network, Sonos uses a mangement protocol called Spanning Tree to make sure that it doesn't create any loops on the network.
Your managed switch(es) is/are likely blocking the Spanning Tree Protocol (STP) packets, which is causing the broadcast storm on the network. If you enable Spanning Tree on your switch that the Sonos components are connected to, and set appropriate cost values for those ports (assuming they are 100Mbps links, the cost value should be 19), the broadcast storms should stop.
If your wired Sonos devices are connected to different switches, you will need to enable Spanning Tree on all of them, and also put appropriate cost values for the links between the switches (Gigabit = 4, 100Mbit = 19, 10Mbit = 100). You may also want to lower the priority value for your "root" switch (the lowest priority device will be the root). The priority can be set in multiples of 4096, with 4096 being the lowest possible value. "
So Sonos devices create them. Someone suggest to disable WiFi on the Sonos devices , but that's not a option, they are in a break room and there are no cables there.
-
"Yes there were a lot of broadcasts."
What is a lot? 5, 10, 100, 1000?
You could have issues if wifi and wired at the same time in the same network.. But that is not the case is it?
Do you have smart switches? Do you have STP disabled? Can you draw up your network.
-
"Yes there were a lot of broadcasts."
What is a lot? 5, 10, 100, 1000?
I haven't counted them roughly I would say 5 every sec from different (Sonos) devices that is.
You could have issues if wifi and wired at the same time in the same network.. But that is not the case is it?
No, see below.
Do you have smart switches? Do you have STP disabled? Can you draw up your network.
Yes,No, sure roughly….
Internet-----xDSLmodem(set as transparent PPPoA to PPPoE bridge)------WAN-pfSense--LAN+VLAN1+VLAN2----Smart Switch1(8 port)
ManagedSwitch1(VLAN1)-----AP1--------AP2
ManagedSwitch1(VLAN2)-----UnmanagedSwitch(24 port)The 3 Sonos devices are connected by WiFi to AP1 or AP2
-
I wouldn't call 5 a second a broadcast storm…
especially if you have multiple macs sending out the traffic - are you seeing duplicates on the mac?
so your smartswitch1 is the same as your managedswitch1 or do you have 2 switch?
Are you running stp? or rstp?
-
I wouldn't call 5 a second a broadcast storm…
Well I Agree, but the AP's they connect has STP set.
especially if you have multiple macs sending out the traffic - are you seeing duplicates on the mac?
Yep
so your smartswitch1 is the same as your managedswitch1 or do you have 2 switch?
Nope It was just to to show that there are 2 VLANs are configured on the same switch.
Are you running stp? or rstp?
STP although the smart switch has RSTP and MSTP
-
Yeah but are they the same forwarded packet or are they new packets.. Where in your setup could you have a loop? Is your unmanaged switch connected more than once to the managed switch?
Your not going to have a broadcast storm unless there is a loop.. Do you have maybe a mismatched native vlans on ends of a trunk, or problem with access ports and mismatched vlans?
Do you have any other device that has wired and wireless at the same time? Again 5 packets second would not be a broadcast storm.. Maybe the devices are just freaking chatty kattys trying to find each other or something. So they are all wireless, do you have client isolation on or something where they can not talk to each other?
So for example just did a quick sniff here.. Someone on the work network is running dropbox and forgot to turn off their lan discovery.. freaking thing throws out 6 packets in less in like .01 seconds.. Its sending out ssdp like once every second, etc..
-
Yeah but are they the same forwarded packet or are they new packets.. Where in your setup could you have a loop? Is your unmanaged switch connected more than once to the managed switch?
Your not going to have a broadcast storm unless there is a loop.. Do you have maybe a mismatched native vlans on ends of a trunk, or problem with access ports and mismatched vlans?
Do you have any other device that has wired and wireless at the same time? Again 5 packets second would not be a broadcast storm.. Maybe the devices are just freaking chatty kattys trying to find each other or something. So they are all wireless, do you have client isolation on or something where they can not talk to each other?
So for example just did a quick sniff here.. Someone on the work network is running dropbox and forgot to turn off their lan discovery.. freaking thing throws out 6 packets in less in like .01 seconds.. Its sending out ssdp like once every second, etc..
I 'll think I'll have to accept those few broadcasts and as the tcpdump relates them to the Sonos device it's just there to stay.
