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.

Nice, good result.

@MrTea Is DNS Resolver listening on the LAN interface?

@rcoleman-netgate said in TAC mails out of the blue...?: @furom We have a lot of old tickets (from the first few months of using the new CRM platform) that did not auto-close and we (TAC staff) were instructed to close them a few months back. I only did mine a month ago and I know that the "feedback" emails come on a schedule based on that close - if there was not one sent it would send again. I get them for internal IT-related tickets. Go figure. That said they're not as {add your adjective here} as MicroCenter sending me feedback emails for things I purchased 60-180 days ago. I even got one last month for something I bought in 2019. Thanks for this explanation! It clears it up better for me. I'm sorry to hear of the mails you get for ancient purchase, hope that has an end to it as well. Given your explanation, I should not receive that many more now then I suppose.

@SteveITS Thank YOU.