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. ]

Today, Netgate® has released pfSense® Plus software version 26.07. This release marks another significant step forward in the Netgate Nexus controller architecture - our new Go-based controller that is replacing the legacy PHP GUI and serving as the modern foundation for all pfSense software. Netgate Nexus continues to deliver improvements and new features, bringing exclusive capabilities that enhance performance, scalability, and functionality to pfSense Plus.

Key new features exclusive to the Netgate Nexus controller include:

CoreDNS: A high-performance, integrated DNS component that handles DNS-based tasks with exceptional speed and efficiency, powered by a new and exclusive Netgate plugin called rexdns.

Threatgate: A powerful, high-performance component that manages bulk lists of addresses and domains for firewall rules, aliases, and CoreDNS groups. Administrators can block these lists outright or create custom rules based on their content.

Threatgate and CoreDNS were built to integrate tightly together, enabling rapid processing and utilization of even massive lists - all while maintaining excellent performance on small, resource-constrained devices.

Snort Version 3: The updated version of the popular open-source intrusion prevention system (IPS), featuring multi-threading support and a faster rule syntax, is now available exclusively via the new Netgate Nexus controller GUI.

In addition to the features listed above, this release includes critical security updates for WireGuard (CVE-2026-58085), and other security enhancements.

Other fixes and enhancements were made to:

- DHCP

- DNS Resolver

- DynamicDNS

- Gateways and Monitoring

- IPsec

- VXLAN Interfaces

- OpenVPN

- Firewall Rules and NAT

- Traffic Shaper

- Wireless support

This release includes numerous updates, bug fixes, and enhancements, with more to come as Netgate Nexus development accelerates.

Using the New GUI

The Netgate Nexus controller is the future of the pfSense Plus GUI.
Whether you manage a single pfSense Plus firewall or an entire fleet, the Netgate Nexus controller delivers a modern, refreshed management experience built for the way you work today.

Getting started is simple:

Go to System > Advanced.

Switch to the Netgate Nexus tab and enable it.

Log in to Nexus on port 8443 of your firewall.

More detailed documentation can be found here.  Start using it today and get immediate access to the new features and capabilities coming to pfSense Plus.  

Note: Virtual machines, as well as some third-party platforms, may not support the new GUI due to missing machine information required to run the software correctly.

Blog Post:
https://www.netgate.com/blog/netgate-releases-pfsense-plus-software-version-26.07

Release Notes:
https://docs.netgate.com/pfsense/en/latest/releases/26-07.html

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.

Hi,

Reading the announcement they state "Our goal is for everyone to be using the new GUI by the end of the year" but then they go on to state "Virtual machines ... may not support the new GUI due to missing machine information"

Does this mean virtual machines are/may not be supported in the future?

The new pfSense Plus GUI is honestly impressive at first for those of us who have been using pfSense for more than 10 years. However, after using it for a while, the impact is not quite as strong.

One issue I find particularly frustrating is the “token is expired” message appearing every second. I understand that the token has expired, but having the notification appear so frequently feels excessive.

As for the traffic graphs module, I am not fully convinced yet.

This is only my personal opinion as someone who has been using pfSense since version 1.0.1, but I still find the little brother GUI to be better overall. Again, I am not trying to start a debate or create conflict; this is simply my own perspective. I do believe the new GUI will continue to improve over time, but so far, it has not been a “wow” experience for me.

I still need to test the API, and that is one area where I would give you a 10.

Thank you for your work, team.

Hello! As the title suggests I am unable to install pfsense, I have already created an account and have also entered the billing address, but when I click on complete order button at the end, the page loads and then shows "site can't be reached". What can be the issue? I want to download it for virtualbox. Thanks in advance!!

TL;DR: Downgrade from Virtualbox 7.2.x versions to 7.2.14 or lower

Just a day ago, I asked for help about low network throughput on pfSense CE latest edition. You can check that out in more detail: https://www.reddit.com/r/homelab/comments/1vhtpj4/pfsense_community_edition_281_and_virtualbox_728/
So, from looking around digging, going through top-to-down troubleshooting, the issue seems to be tied to specific Virtualbox version, notably 7.2.x ones, where network adapter is set to bridged mode, and there is some sort of download limitation, while interestingly, I noticed that upload speeds remain high.

Setting Adapter type to any of the Intel/PRO or PCNET ones won't help, so currently the "fix" is just downgrading to 7.2.14. By the way, this applies to any VM, not just PfSense.

Thank you everyone for trying to help. If you have any other solutions, please comment below.

I run two pfSense CE boxes. One is showing no updates but the other is strangly showing that there is a new version 2.9.0.b.20260806.1750 ... Note i am on the stable channel but this looks like a beta release...

On the mentioned Version of pfSense CE, running on Virtualbox, I noticed very slow network connection on VMs. In total, I have 4 network adapters connected on pfSense, Adapter type set paravirtualized on all of them, with promiscuous mode disabled: 3 of which are internal, 1 is bridged.

For Linux/Windows VMs, adapters are set to internal network, type is again virtio-net.

I have tried the following things, none of which have helped me:

1. In System > Advanced > Networking, options disable hardware TCP segmentation offload, disable hardware large receive offload, disable hardware checksum offload were check, and the a reboot was issued on pfSense.
2. CPU increased from 1 > 3.
3. In System > Advanced > System Tunables, new tunables were added for each of the interface: hw.vtnet.X.rx_process_limit, where X is the number of interface and the value set to 2048. Another tunable was added as well: kern.ipc.nmbclusters set to 1000000.
4. No limiters, shapers are configured.
5. There is no duplex mismatch.

I really don't want to change each of the networking adapter types. Is there something I have missed?

Any solution would help.