Help with Firewall Log
-
192.168.1.1 so they are the same I can change it, but I still don't understand that there can be a IP thats in the LAN range set on the WAN side ???
-
you can not.. if your pfsense lan is 192.168.1.0/24 then no you wouldn't be able to access your isp devices IP of 192.168.1.1 from devices on your lan.
Doesn't mean that device can not have that IP..
For example my cable modem is 192.168.100.1 my lan is 192.168.9.0/24 I can access it just fine without doing anything because pfsense send that traffic out its wan interface and the cable modem picks it up and answers. Some devices might not do that - and you might have to setup a vip on your wan interface to be on the same network as your device, etc..
See the pfsense doc about accessing modem on wan, etc.
-
Thanks I wll look into it it seems according to these http://www.geekzone.co.nz/forums.asp?forumid=66&topicid=196693 that it might be done I will report back also on the 0.0.0.0 port 4944 thanks (so far) for all your time, I am wiser now !!
-
<off topic="">I see my Disk usage ( /mnt ) is 102% of 595MiB - ufs never saw that?</off>
-
<off topic="">I see my Disk usage ( /mnt ) is 102% of 595MiB - ufs never saw that?</off>
Did your tcpdump fill up /mnt?
-
There shouldn't be anything mounted on /mnt unless you're doing something funky.
-
There shouldn't be anything mounted on /mnt unless you're doing something funky.
Yes I did stupid me ;)
-
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
