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

    strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured

    Scheduled Pinned Locked Moved General pfSense Questions
    69 Posts 4 Posters 4.5k Views
    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.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      Ok so it's filtering that MAC on all ports? It will be interesting to see if that stops it logging in pfSense. Or perhaps more interesting if it doesn't! 😉

      E 1 Reply Last reply Reply Quote 0
      • E
        Ellis Michael Lieberman @stephenw10
        last edited by

        @stephenw10
        Yes, it is filtering on all ports.

        I was frustrated as to why the GUI interface for the managed switch didn't allow for MAC filtering. I downloaded the PDF for the switch and found that the CLI allowed for it.

        There are two managed switches on this LAN. The one I configured is the one the router directly connects to on switch port #14. It's a straight CAT6 between the units.

        1 Reply Last reply Reply Quote 0
        • stephenw10S
          stephenw10 Netgate Administrator
          last edited by

          Mmm, interesting. If the mystery device (assuming it exists!) is connected to the other switch ARP broadcasts may still reach clients.

          E 2 Replies Last reply Reply Quote 0
          • E
            Ellis Michael Lieberman @stephenw10
            last edited by

            @stephenw10,

            Are you saying that the packet would show up with the MAC address of the other managed switch and get passed though?

            There are five other unmanaged switches on this network. It that's the case, then it would get through regardless. Of the more than 50 (sometimes 60 with all the cellphones using WiFi, only the router and maybe three other device are directly connected. Everything else comes through other switches. (Of the 16 ports on the main managed switch, ten ports are in use. Four direct to devices and six to switches.)

            1 Reply Last reply Reply Quote 0
            • E
              Ellis Michael Lieberman @stephenw10
              last edited by

              @stephenw10 ,
              I dumped the "show mac address-table" from the switch. The only PC that was running on the LAN was mine and the printer was off line. (This is a quiet time.)

              I ran "Angry IP" at my workstation and did a "stare and compare" of sorts, by copying the dump from the switch into a spreadsheet (sorted by MAC address), and then ran down the the results I got from Angry IP.

              Often the dump from the switch shows a MAC address twice. Adding to the confusion is that many of the CCTV cameras have both a wired Ethernet MAC address and a WiFi MAC address plus the units report both even though only one is functioning frequently resulting in four listings for one camera on the dump. And what you have below is the actual dump of the MAC addresses.

              As an example of the duplicates, the "MagicJack" is directly connected to the main managed switch, yet there are two listings in the dump. The D-link switch does have two listings 28:3b:82:7f:5e:e8, but the WiFi AP connected to it connected has very different MAC address 20:76:93:4e:26:27, as does the CCTV camera connected to it. (Other devices and are connected to it but were not 'on' at the time of the dump.) And the WiFi AP address 20:76:93:4e:23:e3 is connected to unmanaged switch connected to a different mail switch port while the address 20:76:93:50:4a:2b actually directly connected the main switch.

              So, all the MAC addresses match the end device, not a switch port. For your edification, here are the results.

              00:12:31:8f:30:6a	CCTV
              00:12:41:fc:82:a8 	CCTV
              00:12:41:fc:b8:d6	CCTV
              00:12:42:10:0d:72	CCTV
              00:12:43:6b:5a:1e	CCTV
              00:12:43:73:ba:c4	CCTV
              00:2a:2b:fe:80:d1	CCTV
              00:9b:fe:72:d1:2e	CCTV
              00:b5:d0:ef:17:bf	CCTV
              00:c8:1e:63:8d:e8	CCTV
              06:77:f8:74:ab:52	Mobile Phone
              08:00:27:25:77:23 	VirtualBox Server
              08:00:27:77:12:35	VirtualBox Server
              08:00:27:ad:fd:b9	VirtualBox Server
              08:00:27:d9:80:58	VirtualBox Server
              10:27:f5:5d:21:1d	TL-Link AP
              20:76:93:4e:23:e3	WiFI-AP
              20:76:93:4e:26:27	WiFI-AP
              20:76:93:50:4a:2b	WiFI-AP
              22:09:5c:07:1d:2a	BlackBox workstation
              28:3b:82:7f:5e:e8	D-Link Managed Switch
              28:3b:82:7f:5e:e9	D-Link Managed Switch
              28:9c:6e:27:10:ce	Mobile Phone
              2a:03:3e:20:11:7e	VM Host
              30:ff:f6:83:0a:75	CCTV
              30:ff:f6:83:0a:75	CCTV
              30:ff:f6:8f:50:dc	CCTV
              30:ff:f6:8f:50:dc	CCTV
              30:ff:f6:90:ba:94	CCTV
              30:ff:f6:90:ba:94	CCTV
              50:c7:bf:d7:1b:e6	WiFI-AP
              50:c7:bf:d7:1b:e6	WiFI-AP
              54:f1:5f:fc:b1:b6	CCTV
              54:f1:5f:fc:b1:b6	CCTV
              60:be:b4:07:00:b5	Router
              60:be:b4:07:00:b5	Router
              6c:33:a9:1d:27:4b	MagicJack
              6c:33:a9:1d:27:4b	MagicJack
              88:28:7d:38:52:ca	CCTV
              88:28:7d:38:52:ca	CCTV
              88:28:7d:4e:fb:9f 	CCTV
              88:28:7d:4e:fb:9f 	CCTV
              b0:48:7a:e2:5b:86	WiFI-AP
              b0:48:7a:e2:5b:86	WiFI-AP
              b4:fb:e3:36:18:74	CCTV
              b4:fb:e3:36:18:74	CCTV
              b4:fb:e3:36:30:4d	CCTV
              b4:fb:e3:36:30:4d	CCTV
              b4:fb:e3:36:41:c8	CCTV
              b4:fb:e3:36:41:c8	CCTV
              b4:fb:e3:36:44:54	CCTV
              b4:fb:e3:36:44:54	CCTV
              b4:fb:e3:36:47:0c	CCTV
              b4:fb:e3:36:47:0c	CCTV
              b4:fb:e3:39:49:1f	CCTV
              b4:fb:e3:39:49:1f	CCTV
              d6:f1:6e:cf:fe:17	Mobile Phone
              e0:e1:a9:bc:d2:fd	CCTV
              e2:e0:b9:4a:8c:ce	CCTV
              
              1 Reply Last reply Reply Quote 0
              • P
                pfsss @Ellis Michael Lieberman
                last edited by

                @Ellis-Michael-Lieberman @stephenw10
                in my comprehension, my problem is caused by the the large loss at gateway, especially when the download speed is high, and then the system restarts my pppoe gateway, but using a new config called 'ng0' instead of the origin config 'pppoe1'. So no matter how I reconnect, pppoe remains failed unless I reboot my pfsense device to switch to the origin config file.

                is that right?

                E stephenw10S 2 Replies Last reply Reply Quote 0
                • E
                  Ellis Michael Lieberman @pfsss
                  last edited by

                  @pfsss
                  In my case, PPPoE never actually seems to drop. There is no reset. The IP "conflict" is reported, I see, both via the network tool and in real time, a loss of connectivity, but without any rest, all eventually within about 60 seconds comes back stable again. The only thing the log notes is the IP conflict from an unknown MAC address.

                  The error 65 I was experiencing was, today, resolved via a multi-day series of contacts with my ISP that finally got them to resolve something on their side. My only mystery is now the phantom MAC address and the IP address the phantom is creating. There are literally no more log entries in the gateway log. But even after the error 65 errors ended the phantom MAC address issue remained.

                  I have put a block on that MAC address in the managed switch the router is directly connected to as @stephenw10 is convinced it's something on my LAN. The errors can take as much as 36 hours between incidents, so I am just waiting.

                  (In the meantime, there is apparently damage to transpacific fiber cable connecting the Philippines to the USA and Europe. So, if the problem is an outside attack, as a fellow on Reddit is claiming, the cable cut may be dampening the effort. My bandwidth within the Philippines is currently fantastic. I suspect it's because international traffic is hobbled :-) )

                  stephenw10S 1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator @pfsss
                    last edited by

                    @pfsss If you have a WAN with a lot of buffer bloat or just very lossy you may need to tune the gateway monitoring so it doesn't trigger at latency or packet loss levels that are expected.
                    If you only have one gateway you can also just disable the monitoring action for it so it never gets marked down.

                    PPPoE uses NetGraph to create the connections. It is first created as ng0 and then renamed as ppppoe0. That's expected.

                    P 1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator @Ellis Michael Lieberman
                      last edited by

                      @Ellis-Michael-Lieberman Yeah I would expect to see the mystery MAC in the switch table if it passed the switch. But those entries will expire so it would only be there for some time after it appears.

                      No I wouldn't expect to see any traffic from a switch MAC masking the original source unless any of those switches are layer 3 and actually routing.

                      The only time I've seen MAC addresses being 'NAT'd' is when using WIFI extenders which are almost always a terrible idea!

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        @Ellis-Michael-Lieberman said in strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured:

                        00:0c:43:e1:76:29

                        Googling that MAC address shows it's the default used in a bunch of OpenWRT based firmwares. I'd bet this is an access point somehow dropping to it's default values temporarily. I could imagine it doing that at boot when the boot loader checks for PXE boot options. However that would definitely interrupt any wifi devices using it. Unless perhaps you have enough coverage that devices switch APs seamlessly?
                        If the APs you have show uptime that would rule it out.

                        E 1 Reply Last reply Reply Quote 0
                        • E
                          Ellis Michael Lieberman @stephenw10
                          last edited by

                          @stephenw10,
                          There are three APs on the LAN that do use OpenWRT but their uptimes are:

                          30d 19h 5m 25s
                          30d 19h 5m 28s
                          30d 19h 5m 34s
                          

                          The last reboot was following a power outage here. So they were not rebooting recently.

                          There are two Archer APs here, one TP-Link AP and two Comfast APs. They do not appear to use OpenWRT but none have rebooted since the power outage. [We have solar power during the day, with commercial at night with Lithium battery backup for the loss of commercial. There was one night that the commercial was out for so long that the batteries failed. :-) Life in the third world.]

                          The ISP provided as a Bridge (can be set as a router but not in my case) does use OpenWRT but it also didn't reboot and it is on the WAN side. (It's reboot takes about three minutes and the PPPoE session would have needed to be reset.)

                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            Hmm, hard to imagine that MAC would exposed at any time other than at reboot. Unless some process was doing it deliberately, which seems very unlikely.

                            Any of those devices using a Ralink SoC?

                            E 1 Reply Last reply Reply Quote 0
                            • E
                              Ellis Michael Lieberman @stephenw10
                              last edited by

                              @stephenw10

                              No, none of them are using Ralink.

                              1 Reply Last reply Reply Quote 0
                              • P
                                pfsss @stephenw10
                                last edited by

                                @stephenw10
                                my gateway gets down every time I using the Download at very fast speed. the behaviour is strange after gateway gets down, I cannot dial to connect to the ISP unless I reboot the device.

                                gateway monitoring cannot be stopped, because my ISP changes my ip every few days. there should be a monitor to watch the change of gateways.

                                I think ' tune the gateway monitoring' is better way. how to change the gateway monitoring in the web? thanks!

                                1 Reply Last reply Reply Quote 0
                                • stephenw10S
                                  stephenw10 Netgate Administrator
                                  last edited by

                                  The latency and loss alarm values can be set in System > Routing > Gateways: Edit the gateway.

                                  If the ISP changes your IP that should force it to reconnect to update. That shouldn't require gateway monitoring.

                                  E P 2 Replies Last reply Reply Quote 0
                                  • E
                                    Ellis Michael Lieberman @stephenw10
                                    last edited by

                                    @stephenw10 ,
                                    I can see where that might be a problem. I have a static public IP, and no issues with downloads causing problems.

                                    1 Reply Last reply Reply Quote 0
                                    • P
                                      pfsss @stephenw10
                                      last edited by

                                      @stephenw10
                                      if I disable the gateway monitoring , can this affect my ddns service? thanks!

                                      1 Reply Last reply Reply Quote 0
                                      • stephenw10S
                                        stephenw10 Netgate Administrator
                                        last edited by

                                        It would if for example you have DDNS using a failover gateway group. If you only have one gateway though it would not. Changes in the WAN IP would still trigger the DDNS client to update.

                                        However you should disable the gateway monitoring action not the monitoring itself if you choose to do so.

                                        P 1 Reply Last reply Reply Quote 0
                                        • P
                                          pfsss @stephenw10
                                          last edited by pfsss

                                          @stephenw10
                                          hi. after I change the monitoring threshold , this error still happens when I am downloading at very fast speed. here is a error log

                                          Mar 9 00:18:00	sshguard	71108	Now monitoring attacks.
                                          Mar 9 00:18:45	ppp	26135	[wan_link0] LCP: no reply to 1 echo request(s)
                                          Mar 9 00:18:47	check_reload_status	430	Linkup starting re0
                                          Mar 9 00:18:47	kernel		re0: watchdog timeout
                                          Mar 9 00:18:47	kernel		re0: link state changed to DOWN
                                          Mar 9 00:18:47	kernel		re0.1233: link state changed to DOWN
                                          Mar 9 00:18:47	check_reload_status	430	Linkup starting re0.1233
                                          Mar 9 00:18:48	check_reload_status	430	Reloading filter
                                          Mar 9 00:18:48	ppp	26135	caught fatal signal TERM
                                          Mar 9 00:18:48	ppp	26135	[wan] IFACE: Close event
                                          Mar 9 00:18:48	ppp	26135	[wan] IPCP: Close event
                                          Mar 9 00:18:48	ppp	26135	[wan] IPCP: state change Opened --> Closing
                                          Mar 9 00:18:48	ppp	26135	[wan] IPCP: SendTerminateReq #6
                                          Mar 9 00:18:48	ppp	26135	[wan] IPCP: LayerDown
                                          

                                          below is another error log similar to the above

                                          Mar 9 00:05:00	sshguard	91853	Exiting on signal.
                                          Mar 9 00:05:00	sshguard	20179	Now monitoring attacks.
                                          Mar 9 00:05:08	ppp	25847	[wan_link0] LCP: no reply to 1 echo request(s)
                                          Mar 9 00:05:11	check_reload_status	430	Linkup starting re0
                                          Mar 9 00:05:11	kernel		re0: watchdog timeout
                                          Mar 9 00:05:11	kernel		re0: link state changed to DOWN
                                          Mar 9 00:05:11	kernel		re0.1233: link state changed to DOWN
                                          Mar 9 00:05:11	check_reload_status	430	Linkup starting re0.1233
                                          Mar 9 00:05:12	check_reload_status	430	Reloading filter
                                          Mar 9 00:05:12	ppp	25847	caught fatal signal TERM
                                          Mar 9 00:05:12	ppp	25847	[wan] IFACE: Close event
                                          Mar 9 00:05:12	ppp	25847	[wan] IPCP: Close event
                                          Mar 9 00:05:12	ppp	25847	[wan] IPCP: state change Opened --> Closing
                                          Mar 9 00:05:12	ppp	25847	[wan] IPCP: SendTerminateReq #4
                                          Mar 9 00:05:12	ppp	25847	[wan] IPCP: LayerDown
                                          

                                          by the way, the new version of PfSense 2.7.2 has the same 'sshguard Exit' log problem as described in the other post which says affecting all the 2.6 versions.

                                          1 Reply Last reply Reply Quote 0
                                          • stephenw10S
                                            stephenw10 Netgate Administrator
                                            last edited by

                                            @pfsss said in strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured:

                                            Mar 9 00:18:47 kernel re0: watchdog timeout

                                            Try the realtek-kmod driver pkg. If you see that error you should always try that.

                                            P 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.