@dennypage said in Avahi not restarting at boot: I expect that you are using DHCP to acquire an IPv6 delegation from the WAN, and then using it to configure internal interfaces via Track Interface. Unless you are using fully static IPv6, I would recommend that you do not use IPv6 in Avahi. You don't loose anything by having IPv6 disabled in Avahi, and many devices that depend upon mDNS won't use IPv6 even if it is offered. IPv4 works just fine. On pfSense 23.09d-20230921-1219 Avahi does now restart at boot with IPv6 selected. Hurrah! ️

Powerd (with Speedstep) works fine but only if you disable SpeedShift since it takes priority. But you should use Speedshift on any CPU that supports it, it's much better in almost every way.

Hmm, what's shown in the logs when you connect/disconnect the ports?

@stephenw10 Sounds good. I have 16gb RAM and only typically use a tiny percentage of it, and I don't use those packages, so I'll take advantage.

@johnpoz said in pfsense down after a power outage: @heathman56 Not meaning to kick you when your down, but ups is sort of a requirement with any sort of electronic gear. If you do it right since most networking gear is so low power your ups can prob run your network for 30-60 minutes, if not longer and survive 1st world sort of power outages without ever going down. Yep. I have 2 UPS here, one for my main computer and one for pfSense, cable modem, WiFi and switch. In fact I had a power failure last week, where my computer shut down after 15 minutes of failure and then the power came back a minute later. After I turned my computer back on, I was right where I left off. My Internet connection never failed, as that UPS lasts longer than the computer one. I use APCUPSD to shut down the computers when needed.

Hmm, strange indeed! Do you have an OpenVPN server running on the firewall? Does it show the clients connecting to it? What are they supposed to be connecting to? What do you see logged when the webgui cert changes? Steve

@johnpoz I didn't expect to be able to connect to the console with the MicroUSB cable, but I was able to make the connection successfully and reset the admin password. It was a great help! Thank you very much.

did you resolve this? I'm having the same issue

@bingo600 said in NTP widget time wrong?: Hmmm .... Maybe the HW dependent part should be moved to the "Off Topic thread" you made. https://forum.netgate.com/topic/182811/raspberry-gps-based-time-server Sure, now that I know I'm not crazy and the NTP clock is really grunged... I'm good here. I doubt that I'd ever build what you have, but you've got me interested and I'd sure like to follow the build. Use my thread or start your own, I'm cool either way. Rick

@fabriciogcbh said in LDAP group membership: correcting a flaw in the post. it looks like the site removed characters. I couldn't edit, editing timed out. Jim Pingle Solution doesn't work for me &(objectClass=posixGroup)(cn=VPNUsers)(memberUid=*) works for me &(objectClass=posixGroup)(cn=VPNUsers)(member=*)

@JonathanLee ahhh Im on 500/500 Fiber.

@dalvi Hi! Did you find any solution? I'm in the same boat

It would be better to use VLANs on the re(4) NIC for the interfaces than using a USB NIC if you can.

If it was blocking traffic you would see it in the firewall log, unless you had disabled default block logging or added a custom block rule that doesn't log. The errors you're seeing on the client though look like something client side. You might try using dig against the firewall directly to bypass whatever systemd is doing. I have found it can get confused if it starts to see failures. Steve

I'm not aware of that as a bug. Have you seen that across any other upgrades or only from 2.6 to 2.7? What exactly did you have to set to enable the lagg? Do you still have the config diff? Steve

@stephenw10 yeah exactly I would have expected more reports too. Coincidentally we found out about another Netgate 3100 where the same thing happened, and removing the MTU setting resolved their issue as well. So right now I'm aware of 2 cases, both 3100 appliances.

Yes, that's a vulnerability in Chrome and other Chrome-based browsers. Completely unrealted to pfSense. Unless you've somehow installed Chrome in pfSense but I can't begin to imagine what that would require. Or why you would do it! Steve

@Rich-W If I may make a suggestion-- if so, could you try a different gateway server to test your ISP and pFsense? Do you have a spare system that has two Ethernet ports? Do you have access to some free gateway server software? If you do, with the temp gateway server, set its ISP (WAN) side to get the IP address from your ISP, unless that is to be hard coded by you, then do that. If this fails, the ISP is having some kind of routing problems. Now with this gateway server, have it use Class B private for DHCP to the "LAN". This is so there will not be some weird routing issue by double NATing on CLASS C pvt. Use a switch between the gateway LAN and the pFsense WAN ports (so you don't have to make up a special cross-over cable). pFsense should show the correct WAN address and it should be a CLASS B PVT address. Now if you fail on the ISP side of the temp gateway system, that would indicate to me they are having a routing problem. If you fail on the WAN port of pFsense, pFsense appears to be having a problem. I've had to do all this once or twice to figure out what the problem was I was having. And I had a set up like this so that I could test a new gateway server's DHCP for the "LAN" to know I could swap the boxes. I was testing some network appliances I was building several years ago. Regards, Wylbur