@xmacj Perhaps the remote side didn't like something about your original ip address.

I have an ecobee premium (upgraded by ecobee due to wifi issues on a ecobee 3 lite - data drop outs, morse code).

No wifi issues (it's bound to 2.4ghz band). But it does like to phone home to amazon every 50s. None of the amazon features are enabled, but it still insists.

To mitigate this, 2 different measures are in place. On the dns side, only requests to *.ecobee.com are resolved (adguard home). All others return 0.0.0.0 .

On the pfsense side, amazon asn is blocked for this device just in case the dns filters are off (sometimes happens during testing).

@alfredo IIRC this is a FreeBSD issue. I get similar error on my FreeBSD machines in ESXi 7. Does not happen very often but a few times daily. Has never caused any real issues.

Have you tried changing the VMware SCSI controller to LSI SAS instead of VMware Paravirtual? I have read that this can help. I have done so and the LSI SAS machine still has some of these errors.

Cheers,

@stephenw10, that's what i was hoping for! thank you!

@Laxarus said in LDAP Authentication with Active Directory Windows Server 2025, bind fails:

After a sleepless night with lots of troubleshooting, I managed to fix the issue. Anyone who came across this can try the below.

Apparently for some reason pfsense and DC fails to negotiate a proper signing requirements.
I noticed this after inspecting the packet captures which gives me an "unknown CA" error when trying to use SSL.

After modifying the Domain Controller Policy like below, it works now both with SSL disabled and enabled.

Domain Controller Policy
===Computer Configuration
======Policies
=========Windows Settings
============Security Settings
===============Local Policies
==================Security Options
=====================Domain controller: LDAP server channel binding token requirements: "When Supported"
=====================Domain controller: LDAP server signing requirements: "None"
=====================Domain controller: LDAP server Enforce signing requirements: "Disabled"
=====================Network security: LDAP client encryption requirements: "Negotiate Sealing"
=====================Network security: LDAP client signing requirements: "Negotiate Signing"

@Laxarus, your solution works like a charm here! Wouldn't have found this without your help! Thanks a lot for sharing!

@SteveITS I did a cold boot and the serial connection is working now. I was trying serial post boot prior to this and that did not work.

I am good now.

Thank you @patient0 and @SteveITS

@phil-davis said in Traffic Graphc statistics are backwards for LAN interface:

It has always been like that. The graph is with respect to the pfSense interface - so download traffic goes OUT LAN.
The table of clients is with respect to the client - download traffic is IN to the client.
It needs to be this way, because the clients in the table can also be systems out on the public internet (selecting to show "Remote" or "All"). And in that case it looks sensible that the table shows bandwidth out of some public IP and bandwidth in to some LAN client.

Just quoting this comment because, despite being a nearly 10 year old thread, this is the comment that made it click in my head. I had no idea why the graphs worked this way until Phil explained it. Thank you!

@stephenw10 Tried the FreeBSD 15 snapshot 20250227 and it behaves the same way.

@stephenw10 OwnCloud.

@kravenul

First, check why it is slow.
You do this be lookup up what it is doing.
It's one click away : Diagnostics > System Activity

Example :

PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 187 ki31 0B 32K RUN 0 135.7H 100.00% [idle{idle: cpu0}] 11 root 187 ki31 0B 32K CPU1 1 132.5H 90.58% [idle{idle: cpu1}] 85893 root 68 0 150M 64M piperd 1 0:35 8.15% php-fpm: pool nginx (php-fpm){php-fpm} 84969 root 68 0 117M 60M accept 1 0:19 1.56% php-fpm: pool nginx (php-fpm) 65579 unbound 20 0 182M 158M kqread 0 9:16 0.39% /usr/local/sbin/unbound -c /var/unbound/unbound.conf{unbound} 65579 unbound 20 0 182M 158M kqread 1 11:33 0.29% /usr/local/sbin/unbound -c /var/unbound/unbound.conf{unbound} ....

The top resource intensive process are at the top : mine are "being idle" although I'm still routing 300+ Mbytes per sec right now.

Btw :

The dashboard page, deepening on what widgets you have activated, can be somewhat slow as you said yourself : a lot of resources are needed to update that page every x seconds.
Solution : close the page or look at another, more useful page like the log pages.

@kravenul said in pfSense refuses to reboot:

or simply a corrupted file system

It takes a minute to be sure about that, and deal with it. Go here and click play.

Presumably you made some other backups between 2.4.5 and 2.7.2? Did the sizes increase steadily?

I assume the lagg settings must be correct since it works after re-saving.

It does seem like some issue at boot caused by the delay setting up the lagg I agree.

We need to determine exactly what has failed when that happens.

If the WAN/lagg has a valid public IP and the default route shows the correct gateway then I would expect to be able to ping out from Diag > Ping for example. Even if Unbound (the DNS resolver) fails to start the system itself should still be to ping by IP, to 8.8.8.8 for example.

You may not have the required automatic outbound NAT rules preventing LAN side clients connecting. Check Firewall > NAT > Outbound.

Check the system logs after rebooting. I suspect what you will see is that when the WAN connects and gets an IP it is ignored because it happens during the later bootup process.

@stephenw10 said in Pfsense constantly dropping WAN:

@xMrMurderx said in Pfsense constantly dropping WAN:

pfsense drops WAN within 2 minutes of a config save, then 30 seconds later LAN goes down. I'm unable to SSH into pfsense, and using a monitor and keyboard the console is locked up

If the console stops responding that implies some more serious issue. Does it even respond to ctl+t? That can sometimes show something when nothing else does?

Or does the caps-lock key/led work on a directly connected keyboard?

After you reboot do you see anything logged?

Ctrl+t did nothing. Num, caps lock etc lights turn on and off when I hit them, but yeah the console is completely frozen.

This guy has the exact same setup with the same intel nic, same problem as me. There's a few other reddit and forum threads about this specific PC build with intel cards giving the same issues. I just wish I did a little more research before buying the card haha. It's been a little over a month of running stock pfsense because of this issue.

But yeah, problem has been resolved. Threw in a different card I had lying around and everything has fixed itself.

@binary9 said in Crash after setting WAN interface options, now cannot access interface settings page:

Running 23.09-RELEASE (arm64) on a Netgate 2210

I assume you mean 2100 there since it's aarch64?

But that's a known bug: https://redmine.pfsense.org/issues/14949

It was fixed in 23.09.1. You should upgrade! 😉

Or wireguard. Or OpenVPN DCO.

Hmm, hard to imagine anything using that much RAM. But yes check the top output or ps -auxwd.

To close this out, installed a second X550-T2 - The system didn't even need a network device reconfiguration since the network device driver was identical (though my Netgate ID changed - DM'd @stephenw10 to update that on Netgate's end).

Here's my final config:cef9bb6f-3b07-429a-8e3e-eb520a343b2e-image.png

Everything works perfectly. With the CPU power set to ultimate efficiency, while hammering it with speed tests, I only get to 12% CPU usage. If I set the dial to midway between Perf and efficiency, I can't crack 4%. Haven't tried full perf mode yet.

Nice to know I've got power to spare in case I decide to start running more services on the box.

There are likely more efficient ways to set this up, but this works perfectly for my setup as-is. I'll likely move to using VLANs when I do some HW replacement later, but there's no rush.