@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

@stephenw10

I am assuming this from the preboot memory test for the Dell server, which booted without stopping and since I had 3 sites to get back up....onward Christian soldiers?

I'll have to deal with this now. Shit, never a dull moment...

Many thanks and regards, Stephen
oh by the way...nice name!

What monitoring IP are you using on WAN2?

Check the routing table after it comes back up. Do you have the expected IP and subnet shown on WAN2? Is the static route to the monitoring IP re-added?

Steve

You can also see WAN quality graphed in Status > Monitoring.

But, yes, that data is really only useful if you're monitoring something beyond your ISP, like 1.1.1.1 or 8.8.8.8.

Steve

@stephenw10 Good idea on the boot delay. I used 60 sec (did not try 30) and it seemed to work. Thank you!