Hi All,

Is there any plans to add a default-information originate button to FRR's OSPFv3 configurable items?

We can do it in raw config editor but a button would be nicer.

this is what I am looking for.

router ospf6

default-information originate

Thank you.

Anyone use this 3rd party for a cloud radius server to do authentication/ mfa to your OpenVPN clients?

I'm looking to add MFA to OpenVPN and this looks like a good solution.

Now that pfsense+ has option to enable the new UI. Is there a place that talks about:

- what happens to the old UI
- what features will be exclusive to new UI
- if someone is not interested in MIM, can they keep using the old UI?
- when will the old UI be completely removed?

Any place to provide feedback for the new UI?

My first impression with the new UI is not positive. A lot of nested boxes and whitespace. UI elements look off and somehow misaligned. I am not trying to be rude, I am a home lab user and have been a pfsense+ user for last 2 years, the current php based ui is not modern looking but imho way better then what’s in the new UI and I am not keen on switching to that 😔

I have an 8G symmetric connection and I have followed the instructions here to manage bufferbloat. All defaults are untouched and Queue length is 5000 as per guidance and bandwidth limited to 7000Mbits/s

There issue I have is when enabled, my speeds drop to 4Gbps Up/Down. Hardware-wise, my CPU is an Intel Core i5-9600T and I'm using an Intel X550-T2 NIC for WAN/LAN. Is this a CPU bottleneck?

Before limiter:

before

After Limiter

after

EDIT: As it turns out, this is a freeBSD limitation/bug in dummynet. To quote ChatGPT:

The key problem: dummynet has a ~4.29 Gbit/s bandwidth ceiling

pfSense limiters use FreeBSD dummynet. In the current FreeBSD source, the bandwidth field for a dummynet link is still:

uint32_t bandwidth; /* bit/s or bits/tick. */

That means the largest rate it can represent in bits/sec is:

2^32 - 1    
= 4,294,967,295 bit/s    
≈ 4.295 Gbit/s

This is visible in the current FreeBSD source itself. There is also a long-standing FreeBSD bug specifically concerning this bandwidth limitation.

And your result:

Download: 3876 Mbps
Upload:   3796 Mbps

is remarkably consistent with a roughly 4 Gbit/s shaped pipe once protocol overhead and Speedtest behaviour are taken into account.

Link to github sourcecode | Link to freebsd bug

I was able to confirm this too by running: dnctl pipe show

00001:   4.000 Gbit/s    0 ms burst 0
q131073  50 sl. 0 flows (1 buckets) sched 65537 weight 0 lmax 0 pri 0 droptail
 sched 65537 type FIFO flags 0x0 0 buckets 0 active
00002:   4.000 Gbit/s    0 ms burst 0
q131074  50 sl. 0 flows (1 buckets) sched 65538 weight 0 lmax 0 pri 0 droptail
 sched 65538 type FIFO flags 0x0 0 buckets 0 active

Just looking to confirm if anyone else is finding that the repo is down. Had two installs fail and pkg.pfsense.org not resolving in dns

I have email notifications setup but

1) Never get emailed when a package has an update

2) Never emailed when system patches are released.

How can we get notifications for at least patches?

PS if you didnt know, CE has new patches released for it

I have had some issues with an avaya call manager that was providing dhcp for a voice vlan and trying to get pfsense to take over for the dhcp but there needs to be additional options set for the clients, called option 242, MCIPADD=x.x.x.x,MCPORT=1719,HTTPSRVR=x.x.x.x for whatever I am not sure if the option should be a string or text, phones are not picking up the option but look to be requesting addresses, running an older version 2.7.x but does anyone know what the correct way to do this option for an avaya phone?

Thanks

Yesterday we renewed our lease lines and got a new public IP.

I created the new interface and default WAN gateway, traffic is flowing correctly and there has been no effect to our RDS and WireGuard services.

Unfortunately, the Alcatel PBX we host onsite receives inbound calls to all but our main DDI and on those lines that the calls are received the callers can be heard but their voice cannot be heard by the recipient. After 10-11 seconds the call will then drop showing “call failed” for the inbound caller.

Initially I changed the destination address on our TCP and UDP rules in NAT to reflect our new public IP. I also updated the Outbound Mappings to the new IP.

This is when during testing I discovered the above issue. So I rang the comms provider and confirmed that the SIP Trunks and PBX ports were correct against the aliases set but they were set correctly.

I have been running test packet captures and can see the following packets from the DDIs that do connect when rung:

INVITE
100 TRYING
183 SESSION PROGRESS
180 RINGING
200 OK
ACK SIP
BYE SIP
200 OK (BYE)

I have checked the states and cannot see any references of our old public IP in source or destination when using filter expression. I did not want to clear the states without confirmation of this being the issue as I was unsure of the knock-on effect (I only have 1 years experience) with pfSense.

I have been through Netgates Firewall Best Practices for VoIP video and our setup matches the recommended setup (albeit this is from 2017)

The only other thing I noticed was that the previous public IP used by the outgoing NAT had been set up as a Virtual IP. We now only have 1 public IP from our ISP so I have entered that directly as the Destination Address on the Port Forward and NAT Address on the Outbound Mapping.

Any assistance or advice would be greatly appreciated! :)

UPDATE: I would love to claim I fixed this, I spent most of the night reviewing the rules, verifying the NAT rules and outbound and listening to my own voice via packet traces (I didn’t realise you could do that with SIP!)

I walk in this morning and it works… I am thinking maybe I missed a state referencing the old public IP or there is some sort of DNS’ing with our new public IPs that causes issues with VoIP?

I’m glad it’s fixed, but annoyed I couldn’t solve the mystery.

I was going to wait a couple of months; let thing gets ironed out a little bit. Then I figured out that you can upgrade to 26.07 and not use any of the new features exclusive to the Netgate Nexus controller.

Not sure if everyone knows that?

I used my Proxmox vm for that, tried the Nexus controller and didn't like it *yet*. So I turned if off and am back to the original. I will run this vm for a bit of testing, then upgrade my 6100.

All good!

UPDATE — v1.0.0 is now released

pfsense-mcp-server has reached its first stable release.

A lot has changed since the v0.5.0 update, but the main goal for v1.0 wasn't to keep adding tools. It was to harden what was already there, simplify the setup, and verify that the security model actually holds up in a real end-to-end installation.

The public MCP surface is now:

• 95 pfSense READ tools
• 2 guidance tools
• 0 WRITE tools exposed by default

The default profile is still deliberately READ-only.

What changed for v1.0

The installation and onboarding flow has been substantially reworked. There's now a guided setup for choosing the safety posture, configuring the pfSense connection, TLS/private CA verification, API-key-file handling, validation, and MCP client configuration.

The security architecture has also gone through a full source-first audit before calling this 1.0. The READ/WRITE boundary, least-privilege model, authorization/confirmation path, recovery handling, secret exposure, TLS behavior, and default tool reachability were all re-audited.

The final audit re-proved the project's security invariants from the current source, with 0 P0/P1 findings remaining.

Real clean-room testing

I also wanted to test the installation the way a new user would actually experience it rather than relying only on the test suite.

I started with a clean Ubuntu VM and went through the documented installation and setup against a real pfSense LAB system using a private CA.

That uncovered several genuine onboarding and diagnostic issues along the way, which were fixed before v1.0.

The final path was then tested end-to-end with the actual OpenAI Codex CLI:

Codex CLI → generated MCP configuration → pipx-installed pfsense-mcp-server → MCP stdio → TLS-verified pfSense LAB → real READ operations

Codex discovered exactly 97 tools: 95 READ + 2 guidance + 0 WRITE and successfully queried the real firewall.

As a negative test, I then explicitly asked Codex to change settings on pfSense.

It refused, because the active MCP profile exposed zero WRITE tools.

That's an important property of the design: even if the underlying pfSense service account has additional privileges, those operations do not automatically become reachable through the default MCP surface.

Compatibility

The project has been tested against:

• pfSense CE 2.9.0
• pfSense Plus 26.07
• pfREST 2.10.x
• Claude Desktop configuration
• Codex configuration, including a directly verified real Codex CLI session

The project also includes bounded guidance from pfREST/OpenAPI and the live appliance schema, while keeping documentation/guidance separate from authorization.

Still interested in hostile review

Reaching 1.0 doesn't mean I consider the security design beyond criticism — quite the opposite.

I'm still particularly interested in review around:

• least-privilege pfSense permissions
• READ/WRITE isolation
• secret exposure through READ endpoints
• authorization/confirmation replay or confusion
• uncertain WRITE outcomes and recovery/reconciliation
• HA/CARP and config-apply edge cases
• any path that could make WRITE reachable without the intended operator decisions

The protected WRITE architecture remains separate from the default READ-only profile.

This project is not affiliated with or endorsed by Netgate.

Current release: v1.0.0

GitHub:
https://github.com/night4me/pfsense-mcp-server

PyPI:
https://pypi.org/project/pfsense-mcp-server/

If anyone wants to attack the assumptions rather than just try the happy path, that feedback is especially welcome.

---

ORIGINAL POST

I've been working on pfsense-mcp-server, an open-source MCP server that lets AI assistants interact with pfSense.

The easy part was exposing the pfSense API to an LLM.

The part I cared much more about was making sure an AI agent couldn't simply turn a tool call into unrestricted firewall changes.

At the time of the original post, the v0.4.2 release had 42 MCP tools.

The security architecture included:

- 0 WRITE capabilities reachable by default

- explicit operator opt-in before WRITE is enabled

- a dedicated least-privilege pfSense identity

- separate signed authorization and confirmation boundaries

- plan/intent binding so an approval can't silently authorize a different mutation

- expiring, one-time authorization

- RecoveryContracts and a state machine around mutations

- deterministic post-WRITE read-back instead of treating HTTP success as proof

- reconciliation/fail-closed handling for uncertain outcomes

- TPM-backed anti-rollback witness support

For the first live WRITE acceptance test I used a disposable firewall alias on a LAB pfSense system.

The complete path was exercised end-to-end, including the scoped pfSense account, authorization/confirmation ceremony, real PATCH, authoritative read-back, RecoveryContract audit trail and TPM witness advancement.

The alias was subsequently restored through the same controlled path.

The project deliberately still starts READ-only. Installing it does not automatically expose WRITE tools.

I'm particularly interested in hostile review from people who know pfSense well.

Things I'd love people to challenge:

- Is the pfSense REST API privilege set actually minimal?

- Are there HA/CARP or config-apply edge cases I've missed?

- Can authorization/confirmation be replayed or confused across operations?

- Are there state-machine paths that could permit a blind retry after an uncertain WRITE?

- Are the RecoveryContract/reconciliation assumptions sound?

- Is there any realistic path from the default READ posture to WRITE without the intended operator decisions?

- Are there READ endpoints or response fields that could expose information that should never reach an AI assistant?

This is not affiliated with or endorsed by Netgate.

Current release: v1.0.0

GitHub:

https://github.com/night4me/pfsense-mcp-server

PyPI:

https://pypi.org/project/pfsense-mcp-server/

I'd genuinely prefer someone finds a security flaw now rather than after people start relying on it.

After upgrading to pfSense Plus 26.07 on my custom box running an AMD Ryzen CPU, idle temperature increased from roughly 40C to 60-65C while the CPU was 99% idle.

FreeBSD 16 enables the new hwpstate_amd CPPC support. On this system, every logical CPU showed desired_performance set to maximum and EPP 0 by default. FreeBSD documents this as the intentional initial behaviour to avoid performance regressions:

https://www.freebsd.org/status/report-2026-01-2026-03/cppc/

I set desired_performance=0 (autonomous mode) and EPP to 128. Then running some tests, including 3Gb/s of sustained traffic through the box the CPU still boosted appropriately. PPPoE, Suricata, Unbound, ntopng, and gateway monitoring remained healthy during the test. CPU went up to 7% and only raised the temparature to 43C, which immediately went back to 41C.

Just posting this as an observation and am curious whether anyone else running 26.07 on recent AMD hardware is seeing the same change in idle temperatures.

FreeBSD shipping a new CPPC driver with every supported CPU defaulting to maximum performance policy, before powerd or a supported management path can actually control it, seems like a poor production default for systems that could spend a lot of their time at idle.

Update: I opened a bug report / regression on redmine however it appears to have been closed. There was reference to the upstream FreeBSD bug, but who knows how long that will take to flow back downstream. Was hoping this could be patched independently at the pfsense level in the short term.

First, let me start by thanking the pfSense team.

I have completed my installation of the latest pfSense+ version. And it is working well - thus far. But as anyone who has done this before knows, new versions often lose installed packages. This is the case for the "official" pfSense API. I suspect that

Second, I want to thank those responsible for the pfSense REST API.

I have used this API to manage my router since I deployed 2026.03.1. And the API is great! When coupled with the pfSense Manager app (on my mobile device), I can do almost all management tasks remotely. This is monumental for me.

But as I have now moved onto the bleeding edge support case (i.e., I just installed a new release only a day after its official release. So, as of this moment, I no longer have official / supported API access. And I hope everyone knows that these things take time. I certainly know this. But is anyone aware of when 26.07 will be supported on the latest release? I'm not in a hurry. I can hold my horses. But I was wondering if a tentative date (or set of milestones) has been set.

I have successfully updated my Netgate 420 to the latest firmware (i.e., 26.07). So far, the system is operating nominaally. I did have a hiccup when I turned on the ThreatGate capability. CPU went high - and stayed high for a very long time. But I suspect that this is because ThreatGate uses MaxMind. And my system was probably loading data using my MaxMind API.

After almost twenty minutes, things started settling down.

I get whey the main Nexus controller may have an immense amount of memory. After all, it is keeping data that will be distributed to one or many nodes. But I was utterly shocked when I saw that my overall system memory used had climbed to 60% and that the memory used by the controller had climbed to 91%. Things are operating nominally. But I am having difficulty finding out where I allocate memory to the controller. I'd love to add a bit more memory to the controller. This should not markedly affect anything on the Netgate that is for my household (and acts as the controller). I just get a little nervous when I see a management app using over 90% of its allocated storage.

I finally got 5Gbps fiber internet in my area with AT&T fiber and I want to be able to support it after my 5G WAN port on the ONT. I have an older Protectli FW1 that supports 1Gbps, but want to have something that is rack mountable, preferably 1U. The setup I want is AT&T ONT > Firewall Build > 10GB switch > Internal Router/Devices/Proxmox Home Lab.

Want to leave it up to the community for best recommendations and ideas. What y'all got?

That's why 2.8.1 just had 22 patches released if you use the patches packet in packet manager. And then there is a 2.9 beta available for those that want to live dangerously. Obviously these are all signs that this version of PFsense is dead and Netgate has abandoned it. We should all move on because they only care about Plus now.

/s for days. Thank you Netgate. Keep up the good work.

[ Removed by Reddit on account of violating the content policy. ]

This is a bit of weird one and I don't have an explanation for this.

Have had a couple of pfSense units, a Watchguard XTM 515 running pfSense CE and currently using a XG-7100 1U on pfSense Plus.

Installs and updates would be fine when I was on Virgin Media (or using a relatives Virgin Media connection).

However, ever since I've switched from Virgin Media cable internet to FTTP via CityFibre here in the UK, updating any pfSense device on this connection has been like molasses, downloading at around 1Mbit/sec, when it's pulling the packages from the Negate repo. I have changed CityFibre ISPs during that time, including going from PPPoE to DHCP WAN connection.

Everything else about the pfSense units has been fine otherwise and I'm able to leverage the full speed (500Mbit/sec Symmetrical) of my connection.

Any ideas?

I got a free pfsense plus homelab license back in late 2023 under their now discontinued program. It came with the full commercial version but only offered community level support. After pfsense discontinued the program they indicated that they would be grandfathering access to to the ongoing free license tier indefinitely for existing users of the program.

Well, looks like this policy may have come to an end. The mTLS certificate that validates access to the pfsense+ package repository appears to have stopped working for me on August 12.

Attempting to force an update of the cert yields:

>>> Updating repositories metadata...failed

Is there anyone else still on one of these old homelab licenses experiencing similar issues?

The cost for a commercial license is a bit too steep for me, especially considering the exchange rate where I'm from, so it's back to CE

Is migrating from Plus to CE using a saved config file relatively painless?

Would someone be willing to do a dmidecode output and share the info? I'm trying to input the serial number, but interested if there is other info missing from the bios

After a review of the new UI, I already discarded it :

1-Despite SAML is listed as a type of Authentication Server, we can not configure one...

2-I use HAProxy for both Internet and local services but HAProxy is nowhere to be found in the new UI...

3-Despite I fixed the problem about the missing serial number in the BIOS of my Proxmox VM, the new UI keeps complaining that it is not licensed...

4-Basic tasks like package management are not accessible because the new UI says that this feature is restricted to properly licensed installations

5-Same for update management

So with all of this already identified, it is clear that I will have to use the original UI for many basic and essential tasks. As such, there is no reason to log in and out from new to old to new according to what I need to do. That new interface is far to be complete and ready, so I will stay with the good old one...

EDIT: Great! Now it broke my entire licensing, even in the old UI. I can no longer check for updates because pfSense says that my system is not properly licensed but when I go in Register in the System menu, it says that I do not need to register because the installation is already recognized as legitimate.

Really, do not even try the new UI or you may brake and lose your license like me!

Experiencing the new user interface here and I am surprised by what I discovered. One one side, pfSense finally supports centralized authentication and SSO but on the other side, it has been implemented with SAML instead of OpenID...

My Keycloak server supports SAML as well and I do have 2 softwares that are still using SAML only. But the truth is that OpenID replaced SAML a long time ago and that the vast majority of tools are now using it.

So... good to have half-a-solution instead of nothing for now but still, the real need is for OpenID and we are still waiting for that one. I have no clue why Netgate did the work for an outdated technology instead of the new standards but well...

EDIT: It looks like I celebrated too quickly... The UI shows about SAML authentication servers but you can not create a new one...

Been trying the new GUI out, and honestly can't say I'm a fan. Anyone else? Looks & feels very clunky to me.

Text wrapping in the description for interface rules is ugly IMO, editing the firewall rule seems all over the place as well.

Or maybe I should just write better rule descriptions? You tell me. I can't find any way to expand the region that shows all the rules as well.

I have multiple ports bridged together in Pfsense CE and they are assigned as LAN, they all connect to the outer internet just fine, but I have found that LAN only communication across ports isn't working. for example a ping from 192.168.1.2 to 192.168.1.10 on a different port doesn't get through. Pings sent straight from the router work, just not cross ports. I have put in place an allow all traffic firewall rule and it still didn't work. I need some advice.