Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Help with Firewall Log

    Firewalling
    6
    43
    6824
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Qinn
      Qinn last edited by

      Hi see the following in the logging about every many times, what is it?

      Act Time         IF Source Destination
      X Aug 6 11:00 em0 0.0.0.0 255.255.255.255:4944
      X Aug 6 10:59 em0 0.0.0.0 255.255.255.255:4944
      X Aug 6 10:59 em0 0.0.0.0 255.255.255.255:4944
      X Aug 6 10:59 em0 0.0.0.0 255.255.255.255:4944
      X Aug 6 10:59 em0 0.0.0.0 255.255.255.255:4944

      Found https://forum.pfsense.org/index.php?topic=100896.msg562758#msg562758 so it's Bogon?

      btw em0  is the WAN and I use 2.3.2-RELEASE (i386) with pfBlockerNG 2.1.1_2w/DNSBL

      Thanks for any help,

      Cheers Qinn

      1 Reply Last reply Reply Quote 0
      • johnpoz
        johnpoz LAYER 8 Global Moderator last edited by

        4944 is not a registered port.  I can find no info on what application/service would send such traffic.

        Is it udp or tcp?  I would really sniff that traffic and open it up in wireshark to see.. 0.0.0.0 is listed in bogon.. But that doesn't mean it is, a client asking for dhcp would send from 0.0.0.0 etc..  But not to port 4944.

        If all your wanting to do is clear up your log you could set a rule to not log the traffic.  But I would be curious what it is so I wold setup packet capture under diag, and then download that file and either post it here or load it up your self in say wireshark..

        How much of it are you seeing?  Is your log just full of it, hundreds of packets a second, a minute, a day?  What?

        1 Reply Last reply Reply Quote 0
        • N
          Nullity last edited by

          I am interested to see what a packet capture shows as well…

          1 Reply Last reply Reply Quote 0
          • P
            Paint last edited by

            Same. This issue looks odd.  Please capture the packets

            1 Reply Last reply Reply Quote 0
            • Qinn
              Qinn last edited by

              @johnpoz:

              4944 is not a registered port.  I can find no info on what application/service would send such traffic.

              Is it udp or tcp?  I would really sniff that traffic and open it up in wireshark to see.. 0.0.0.0 is listed in bogon.. But that doesn't mean it is, a client asking for dhcp would send from 0.0.0.0 etc..  But not to port 4944.

              If all your wanting to do is clear up your log you could set a rule to not log the traffic.  But I would be curious what it is so I wold setup packet capture under diag, and then download that file and either post it here or load it up your self in say wireshark..

              How much of it are you seeing?  Is your log just full of it, hundreds of packets a second, a minute, a day?  What?

              Thanks for you help ;)

              Status/System/LogsFirewall/Normal View

              Aug 6 18:40:32 em0 0.0.0.0:15217 255.255.255.255:4944 UDP
              Aug 6 18:40:22 em0 0.0.0.0:15154 255.255.255.255:4944 UDP
              Aug 6 18:40:12 em0 0.0.0.0:15100 255.255.255.255:4944 UDP
              Aug 6 18:40:02 em0 0.0.0.0:15055 255.255.255.255:4944 UDP
              Aug 6 18:39:52 em0 0.0.0.0:15019 255.255.255.255:4944 UDP
              Aug 6 18:39:42 em0 0.0.0.0:14992 255.255.255.255:4944 UDP

              There seems to be repetition every 00:00:10

              1 Reply Last reply Reply Quote 0
              • P
                Paint last edited by

                @Qinn:

                @johnpoz:

                4944 is not a registered port.  I can find no info on what application/service would send such traffic.

                Is it udp or tcp?  I would really sniff that traffic and open it up in wireshark to see.. 0.0.0.0 is listed in bogon.. But that doesn't mean it is, a client asking for dhcp would send from 0.0.0.0 etc..  But not to port 4944.

                If all your wanting to do is clear up your log you could set a rule to not log the traffic.  But I would be curious what it is so I wold setup packet capture under diag, and then download that file and either post it here or load it up your self in say wireshark..

                How much of it are you seeing?  Is your log just full of it, hundreds of packets a second, a minute, a day?  What?

                Thanks for you help ;)

                StatusSystem/LogsFirewall/Normal View

                Aug 6 18:40:35 WLAN 0.0.0.0 224.0.0.1 IGMP
                Aug 6 18:40:34 WLAN 0.0.0.0 224.0.0.1 IGMP
                Aug 6 18:40:32 em0 0.0.0.0:15217 255.255.255.255:4944 UDP
                Aug 6 18:40:22 em0 0.0.0.0:15154 255.255.255.255:4944 UDP
                Aug 6 18:40:12 em0 0.0.0.0:15100 255.255.255.255:4944 UDP
                Aug 6 18:40:02 em0 0.0.0.0:15055 255.255.255.255:4944 UDP
                Aug 6 18:39:52 em0 0.0.0.0:15019 255.255.255.255:4944 UDP
                Aug 6 18:39:42 em0 0.0.0.0:14992 255.255.255.255:4944 UDP

                Do you have DSL? Search on Google and the forums for. "igmp 4944"

                https://forum.pfsense.org/index.php?topic=92054.0

                1 Reply Last reply Reply Quote 0
                • Qinn
                  Qinn last edited by

                  @Paint:

                  @Qinn:

                  @johnpoz:

                  4944 is not a registered port.  I can find no info on what application/service would send such traffic.

                  Is it udp or tcp?  I would really sniff that traffic and open it up in wireshark to see.. 0.0.0.0 is listed in bogon.. But that doesn't mean it is, a client asking for dhcp would send from 0.0.0.0 etc..  But not to port 4944.

                  If all your wanting to do is clear up your log you could set a rule to not log the traffic.  But I would be curious what it is so I wold setup packet capture under diag, and then download that file and either post it here or load it up your self in say wireshark..

                  How much of it are you seeing?  Is your log just full of it, hundreds of packets a second, a minute, a day?  What?

                  Thanks for you help ;)

                  StatusSystem/LogsFirewall/Normal View

                  Aug 6 18:40:35 WLAN 0.0.0.0 224.0.0.1 IGMP
                  Aug 6 18:40:34 WLAN 0.0.0.0 224.0.0.1 IGMP
                  Aug 6 18:40:32 em0 0.0.0.0:15217 255.255.255.255:4944 UDP
                  Aug 6 18:40:22 em0 0.0.0.0:15154 255.255.255.255:4944 UDP
                  Aug 6 18:40:12 em0 0.0.0.0:15100 255.255.255.255:4944 UDP
                  Aug 6 18:40:02 em0 0.0.0.0:15055 255.255.255.255:4944 UDP
                  Aug 6 18:39:52 em0 0.0.0.0:15019 255.255.255.255:4944 UDP
                  Aug 6 18:39:42 em0 0.0.0.0:14992 255.255.255.255:4944 UDP

                  Do you have DSL? Search on Google and the forums for. "igmp 4944"

                  https://forum.pfsense.org/index.php?topic=92054.0

                  Yes I have aDSL Thanks for you help ;)

                  I did a capture (Diagnostics/Packet Capture) but it stays empty, I choose WAN as interface any-any and 0.0.0.0 for host => nothing even with and without Enable promiscuous mode still nothing, am I doing something wrong or should I move over to wireshark. Why is the log mentioning em0 and not WAN btw?

                  Thanks to all that replied for your help !

                  1 Reply Last reply Reply Quote 0
                  • Qinn
                    Qinn last edited by

                    https://forum.pfsense.org/index.php?topic=92054.0

                    Strange thing is I have Draytek Vigir 130 to. Mine is in PPPoA to PPPoE bridge mode so it's transperant.

                    1 Reply Last reply Reply Quote 0
                    • Derelict
                      Derelict LAYER 8 Netgate last edited by

                      Just capture on WAN with the port set to 4944. Leave the hosts as any.

                      1 Reply Last reply Reply Quote 0
                      • Qinn
                        Qinn last edited by

                        @Derelict:

                        Just capture on WAN with the port set to 4944. Leave the hosts as any.

                        Only filled in the port and set the count to 1 waiting for over 10min still the capture is running, stopped it and the log file is empty? On the status/dashboard/firewall logs there are numerous counts of "em0 0.0.0.0  to 255.255.255.255:4944" (still don't understand why the log is mentioning em0 in stead of WAN).

                        I still wanna analyze this strange log in the firewall, but just out of curiosity I unchecked the logging of block bogon networks (status/system logs/settings), but it doesn't help they are still in the logs?

                        I tested a simple (so with default setting any-any) capture on the WAN and it's working fine, strangely but consistent, there are no captures on 0.0.0.0. in this file?

                        1 Reply Last reply Reply Quote 0
                        • johnpoz
                          johnpoz LAYER 8 Global Moderator last edited by

                          wan is going to be assigned to an interface..  What are you interface assignments?  Can you post them.  Is your wan actually a vlan on top of em0?

                          Use tcpdump directly with -i em0 and port udp 4944..  If you see the traffic then you can write it to a file and we can open it in wireshark.

                          1 Reply Last reply Reply Quote 0
                          • Qinn
                            Qinn last edited by

                            @johnpoz:

                            wan is going to be assigned to an interface..  What are you interface assignments?  Can you post them.  Is your wan actually a vlan on top of em0?

                            Use tcpdump directly with -i em0 and port udp 4944..  If you see the traffic then you can write it to a file and we can open it in wireshark.

                            NIC1 = em0 = WAN
                            NIC2 = em1 = LAN
                            on em1 I have assigned 2 VLAN's

                            tcpdump -> wireshark thanks for pointing that one out to me!

                            So I did a

                            tcpdump -c  10 -w /tmp/port.4944.debug.txt -i em0 'port 4944'

                            than I looked at it with wireshark. To my limited knowledge it seems it originates from the the PPPoA to PPPoE bridge (Draytek Vigor 130) which is between WAN(em0) and ISP as this ISP uses PPPoA and as far as I know this cannot be done by pfSense. I though this bridge should be transparent? I would like to know our opinion  insights, thanks for having a look in advance.

                            1 Reply Last reply Reply Quote 0
                            • johnpoz
                              johnpoz LAYER 8 Global Moderator last edited by

                              So did you go into your daytek and

                              UNmarking "Broadcast DSL status to LAN" under ->System Maintenance->Management

                              1 Reply Last reply Reply Quote 0
                              • Qinn
                                Qinn last edited by

                                @johnpoz:

                                So did you go into your daytek and

                                UNmarking "Broadcast DSL status to LAN" under ->System Maintenance->Management

                                I will take a look at it and report back soon, at this time it is not possible to power it down. Not to be on hasty side, but I thought a Draytek Vigor 130 set into PPPoA to PPPoE and as so bridging between ISP and WAN was totally transparent.

                                btw if you have taken a look I remove the file as there's a mac address in there you can't be to carefull ;)

                                1 Reply Last reply Reply Quote 0
                                • johnpoz
                                  johnpoz LAYER 8 Global Moderator last edited by

                                  why would you have to power it down?

                                  1 Reply Last reply Reply Quote 0
                                  • Qinn
                                    Qinn last edited by

                                    As I said settings it to bridge mode between PPPoA and PPPoe, to the best of my knowledge it has no IP (that's why I said it was transparent) so I don't know how to login on it, is there a way? The moment I disconnect it from the Internet it get's an IP (static).

                                    1 Reply Last reply Reply Quote 0
                                    • johnpoz
                                      johnpoz LAYER 8 Global Moderator last edited by

                                      well my cable modem is "transparent" ie pfsense gets a public IP..  And I can still access the cable modem via 192.168.100.1 - I would assume daytek would have the same sort of default IP for management even when in "bridge" mode.

                                      1 Reply Last reply Reply Quote 0
                                      • Qinn
                                        Qinn last edited by

                                        http://just.draytek.com/index.php?option=com_k2&view=item&id=5617&Itemid=293&lang=en From what the specs say it seems that it could send DSl info (you are wright, still not checked it in the hardware though  ;) ), although I never checked this option and as I know not how to access it, I am still mandatory to power it down and connect it to my LAN as I don't know how to set an IP as It is on on the WAN side?

                                        1 Reply Last reply Reply Quote 0
                                        • johnpoz
                                          johnpoz LAYER 8 Global Moderator last edited by

                                          well the IP by default is 192.168.1.1 I think - this might be the IP even when in bridge mode.

                                          What IP you using on pfsense lan side?

                                          1 Reply Last reply Reply Quote 0
                                          • Qinn
                                            Qinn last edited by

                                            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  ???

                                            1 Reply Last reply Reply Quote 0
                                            • johnpoz
                                              johnpoz LAYER 8 Global Moderator last edited by

                                              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.

                                              1 Reply Last reply Reply Quote 0
                                              • Qinn
                                                Qinn last edited by

                                                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 !!

                                                1 Reply Last reply Reply Quote 0
                                                • Qinn
                                                  Qinn last edited by

                                                  <off topic="">I see my Disk usage ( /mnt ) is  102% of 595MiB - ufs never saw that?</off>

                                                  1 Reply Last reply Reply Quote 0
                                                  • N
                                                    Nullity last edited by

                                                    @Qinn:

                                                    <off topic="">I see my Disk usage ( /mnt ) is  102% of 595MiB - ufs never saw that?</off>

                                                    Did your tcpdump fill up /mnt?

                                                    1 Reply Last reply Reply Quote 0
                                                    • Derelict
                                                      Derelict LAYER 8 Netgate last edited by

                                                      There shouldn't be anything mounted on /mnt unless you're doing something funky.

                                                      1 Reply Last reply Reply Quote 0
                                                      • Qinn
                                                        Qinn last edited by

                                                        @Derelict:

                                                        There shouldn't be anything mounted on /mnt unless you're doing something funky.

                                                        Yes I did stupid me  ;)

                                                        1 Reply Last reply Reply Quote 0
                                                        • Qinn
                                                          Qinn last edited by

                                                          @johnpoz:

                                                          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!!

                                                          1 Reply Last reply Reply Quote 0
                                                          • Qinn
                                                            Qinn last edited by

                                                            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!

                                                            1 Reply Last reply Reply Quote 0
                                                            • johnpoz
                                                              johnpoz LAYER 8 Global Moderator last edited by

                                                              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 ;)

                                                              1 Reply Last reply Reply Quote 0
                                                              • Qinn
                                                                Qinn last edited by

                                                                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.

                                                                1 Reply Last reply Reply Quote 0
                                                                • K
                                                                  kpa last edited by

                                                                  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.

                                                                  1 Reply Last reply Reply Quote 0
                                                                  • johnpoz
                                                                    johnpoz LAYER 8 Global Moderator last edited by

                                                                    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.

                                                                    1 Reply Last reply Reply Quote 0
                                                                    • Qinn
                                                                      Qinn last edited by

                                                                      @johnpoz:

                                                                      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.

                                                                      1 Reply Last reply Reply Quote 0
                                                                      • johnpoz
                                                                        johnpoz LAYER 8 Global Moderator last edited by

                                                                        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..

                                                                        1 Reply Last reply Reply Quote 0
                                                                        • Qinn
                                                                          Qinn last edited by

                                                                          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.

                                                                          1 Reply Last reply Reply Quote 0
                                                                          • johnpoz
                                                                            johnpoz LAYER 8 Global Moderator last edited by

                                                                            "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..

                                                                            1 Reply Last reply Reply Quote 0
                                                                            • Qinn
                                                                              Qinn last edited by

                                                                              @johnpoz:

                                                                              "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.

                                                                              1 Reply Last reply Reply Quote 0
                                                                              • johnpoz
                                                                                johnpoz LAYER 8 Global Moderator last edited by

                                                                                "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.

                                                                                1 Reply Last reply Reply Quote 0
                                                                                • Qinn
                                                                                  Qinn last edited by

                                                                                  @johnpoz:

                                                                                  "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

                                                                                  1 Reply Last reply Reply Quote 0
                                                                                  • johnpoz
                                                                                    johnpoz LAYER 8 Global Moderator last edited by

                                                                                    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?

                                                                                    1 Reply Last reply Reply Quote 0
                                                                                    • First post
                                                                                      Last post

                                                                                    Products

                                                                                    • Platform Overview
                                                                                    • TNSR
                                                                                    • pfSense Plus
                                                                                    • Appliances

                                                                                    Services

                                                                                    • Training
                                                                                    • Professional Services

                                                                                    Support

                                                                                    • Subscription Plans
                                                                                    • Contact Support
                                                                                    • Product Lifecycle
                                                                                    • Documentation

                                                                                    News

                                                                                    • Media Coverage
                                                                                    • Press
                                                                                    • Events

                                                                                    Resources

                                                                                    • Blog
                                                                                    • FAQ
                                                                                    • Find a Partner
                                                                                    • Resource Library
                                                                                    • Security Information

                                                                                    Company

                                                                                    • About Us
                                                                                    • Careers
                                                                                    • Partners
                                                                                    • Contact Us
                                                                                    • Legal
                                                                                    Our Mission

                                                                                    We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                                                                    Subscribe to our Newsletter

                                                                                    Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                                                                    © 2021 Rubicon Communications, LLC | Privacy Policy