You need to NICS.... One for WAN and one for LAN. Add the VLAN's on the LAN parent interface. That the way (best practice).

I'm not aware of a limit there. You might hit usability issues in the webgui eventually.

Mmm, unfortunately there isn't really any other options there. There are a lot of cases where more fine grained notification control would be useful. There's probably already a feature request open but if not you can add one: https://redmine.pfsense.org/ Like: https://redmine.pfsense.org/issues/12531

There isn't yet an Plus installer image for whitebox devices. We are currently working on it. You can now upgrade directly from 2.7 to 23.05.1 though.

@mohie25 said in Captive Portal client exemption: have you found a solution for this problem These : [image: 1691574763340-3c4bf949-3894-4e6a-a5e1-bce4c480a6ad-image.png] are 3 IPs, my access points. These can access the Internet without being blocked by the portal while in the portal network. My captive portal uses 192.168.2.0/24 - it's a dedicated network for my clients. Special case ( ? ) discovered this week, I was shown a possible issue that if the 'french' (or another ?) language is used, the "Allowed IP Addresses" don't work. Temporary solution : Use the default GUI language. edit : in 2016, pfSEnse was completely different. Issues form then (which wasn't an issue because it worked very well in 2016 ... that is, it does so since 2009 for me) don't make sense today. That is, if you are not using pfSense 2.0.x

@gstlouis That is a configuration on the Firewall itself, Auto Power on when Failure, It is a setting in the BIOS, I have configured my Firewalls and Firewalls in other locations to Power on Automatically which is configured in the BIOS.

That's a drive issue: sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: ============== REGISTER DUMP ============== sdhci_pci0-slot0: Sys addr: 0x14366200 | Version: 0x00001002 sdhci_pci0-slot0: Blk size: 0x00000200 | Blk cnt: 0x00000000 sdhci_pci0-slot0: Argument: 0x000138b0 | Trn mode: 0x00000003 sdhci_pci0-slot0: Present: 0x1fff0000 | Host ctl: 0x00000025 sdhci_pci0-slot0: Power: 0x0000000b | Blk gap: 0x00000080 sdhci_pci0-slot0: Wake-up: 0x00000000 | Clock: 0x00000207 sdhci_pci0-slot0: Timeout: 0x0000000d | Int stat: 0x00000003 sdhci_pci0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003a sdhci_pci0-slot0: AC12 err: 0x00000000 | Host ctl2:0x0000000c sdhci_pci0-slot0: Caps: 0x546ec8b2 | Caps2: 0x80000007 sdhci_pci0-slot0: Max curr: 0x00000000 | ADMA err: 0x00000000 sdhci_pci0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000001 sdhci_pci0-slot0: =========================================== mmcsd0: Error indicated: 1 Timeout The actual crash shows a filesystem problem but that would be caused by the drive timeout and resulting reboot. The logs are pretty much full on arp movement spam. If that's a known device you might want to disable logging it: https://docs.netgate.com/pfsense/en/latest/troubleshooting/logs-arp-moved.html You are still running 2.4.4 which is an ancient release. Steve

@stephenw10 Quite sure i had an external ip in my macbooks arp table Have abandoned the virtualised firewall idea for now, will probably look at a hardware device.

@Gertjan @stephenw10 Thank you both for the great help! :) My pfSense is up and running as I wanted!!! I really appreciate the help you both provided. [image: 1691519265761-af912013-1dbe-4c13-bfc5-b286d0ecf371-image.png]

@stephenw10 I will try to use my TP Link router to check tomorrow. I am not very optimistic on this as it seems nothing more I can do nor any solutions out there.

@stephenw10 said in CPU usage increase suddenly: Yes, 60s is very short. Any reason it was set to that? Reply I stood up new DNS servers and wanted devices to cut over right away which worked but caused an issue for myself. This entire issue smelled like a config problem but i couldn't prove it at the time. I went against my rule of rebooting the firewall as i truly dislike doing that especially if things were working before.

@stephenw10 thanks Stephen, this can be closed.

@Happydog said in PfSense no DHCP on VLANs for UniFi WiFi controller: VLAN tag takes a long time (5+ minutes) to get an IP Well why not just sniff on pfsense, or even look in the dhcp log. So for example here here is dhcp on a tagged vlan ID 4 on pfsense.. Here is my phone connecting - you can see the discover, the offer, the request and then the ack. [image: 1691447554526-dhcp.jpg] The whole process took 2 seconds. Do you have like dhcp guarding or snooping enable in your unifi setup? [image: 1691447920983-dhcpsnoop.jpg] edit: You could be having issue with broadcast being dropped? What firmware are you running on the AP... I recall there was some issue back a while ago where specific firmware had a problem with this.. Many moons ago that was, but maybe your firmware is really old? Could have something to do with band steering and client having actual issue with connecting, then once the wifi connection is actually made - then the dhcp has to happen. Heer you can see where my phone disconnected from the ssid it was on, connected to the other ssid that was the above dhcp logs and sniff. Time matches up, too bad it doesn't show seconds in the log.. but you can see where I moved from one ssid and then to another ssid and then the phone moved back to its preferred ssid. I have the ssids blocked out for privacy - ssids can be looked up in dbs online. And my ssids are very unique.. They are not just typical linksys ;) [image: 1691448545699-connected.jpg] edit2: on your controller - on the dashboard, under wifi insights are you showing any problems in the connectivity tab with any problem clients listed, etc. Or any issues with any of the details shown there? [image: 1691449082896-connectivity.jpg]

Additionally I added: [23.05.1-RELEASE][admin@azure53.stevew.lan]/root: ln -s /usr/bin/base64 /usr/local/bin/base64 That doesn't appear to be required but it does remove a large number of errors from the waagent logs so I assume it's doing something! I tested restoring from the backups and it was successful. Steve

@sgw said in Undefined symbol "__libc_start1@FBSD_1.7" on pfSense Plus 23.01: I hit this issue again on a SG-7100 today Still on 23.01? The best time to upgrade it is yesterday.