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!

It's the last thing in the message buffer before the kernel trap:

VMware memory control driver initialized [fib_algo] inet.0 (bsearch4#32) rebuild_fd_flm: switching algo to radix4_lockless aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS> kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode

And it's unusual to see the aesni device loaded at that point. It would normally be loaded during bootup if it was already enabled.

@johnpoz said in Virtual IP subnet cannot connect to internet:

@BlueSun said in Virtual IP subnet cannot connect to internet:

There's an Automatic NAT Rule, which I don't see

You said your outbound rules were auto and it was added, I was just adding that screen for completeness

Well, I set the outbound NAT rules to Automatic, but for some odd reason it didn't create the rules you have in your screenshot, so I had to add them manually.

d60a6317-0b25-4106-b407-971b002cdac0-image.png

Hmm, I'm not sure anything can disable that other than manually. Can you see a change in the config history that disabled it?

You can use igb1 you just can't add igb1 to a bridge. Though I always prefer not to see tagged and untagged traffic on an NIC if possible because it avoids config errors causing problems.

Yes, you can still bridge the VLAN interfaces.