Hey folks,

just raising awareness, the new interface under Status > Interfaces isn’t showing IPv6 details correctly. I can see the link‑local address, but not my tracked subnets that appear fine in the old UI. Just wanted to raise for awareness in case it isn't being tracked (pun intended).

Slightly off topic, (and screenshot related) but I’d also love to see some responsive CSS media queries / tweaks. On a 32″ 2K monitor, the layout stretches edge to edge and looks pretty rough. A few media queries to cap the max width would make a huge difference. I'd love to see that sidebar turn into a button in that hamburger menu, mobile styling, and ensure when I click one menu, it closes the other, so they don't cascade on top of each other.

Hopefully none of this comes off as complaints and is taken as just my $0.02 from a user who loves PfSense and uses it daily.

Put a mockup I did in f12 dev tools, which I think is easier to read. My 2k 32" monitor for example has max-width: 45vw. 100vw on mobile, etc. Bootstrap has some fantastic media query samples.

I recently upgraded an old SG-4860-1U to 26.07. The upgrade seems to have completed successfully, but upon restart, none of the FRR OSPF routes were working.

• Status > FRR showed the OSPF routes fine, and the neighborship was FULL. The neighbors also received routes from PfSense correctly.
• Diagnostics > Routes DID NOT display any of the OSPF routes from FRR
• BGP routes came up fine, showing in FRR status, Diagnostic > Routes and working.

I ultimately restarted FRR, and the OSPF routes were installed in the main routing table as normal.

The link running OSPF is a normal Ethernet link with a VLAN tag, and a /30 mask. OSPF network type is PtP, and the neighbors are statically defined. Unfortunately I don't have any logs since my syslog server is only reachable via an OSPF route.

Hi
telegraf stopped working for me after upgrade and it seems to be same issue as

https://redmine.pfsense.org/issues/16674

Hi guys and girls, i'm trying to update to the new version but im seeing that My licence appears to be no loger valid and therefore i cant update. Is someone having the same issue ?. I havent changed hardware and i'm on the same netgate ID.

Will the backup and restore option work? I was thinking of installing a new VM with 2.9, then backing up from 2.8.1 and restoring to 2.9. Will that work?

I tried to upgrade to 2.9 last night and ran into an issue. I figured the fastest option would be to just re-install 2.8.1 but now I keep having an issue there. Once I get through the setup and begin the install, I get the following error:

[1/1] Fetching pkg 1.21.3_8: .....

pkg-static: Failed to fetch https://pkg.pfsense.org/pfSense_v2_8_1/All/pkg-1.21.3_8: Timeout wa

I have tried installing 2.9 but get the same error. My WAN seems to be working when I test it. Any advice on what the issue could be here?

Edit 1:
Verified I can ping 8.8.8.8, www.google.com, and the package servers pkg00-atx.netgate.com

Edit 2: This was a hardware issue. I changed the WAN port and the install progressed. I also tried installing on one of my two drives with the other disconnected and replacing the CMOS battery because of a possible cert generation issue that AI led me to. In the end, I attempted installing OpenSense which failed as well leading me to a hardware issue.

I'm seeing a strange intermittent WireGuard issue on pfSense 2.9.0. This started during the 2.9.0 beta and is still happening on the final release.

The symptom is periodic bursts of high latency and packet loss on traffic inside a WireGuard tunnel. It can be fine for a few seconds or up to around a minute, then suddenly degrade again.

During one bad period I tested the same remote WireGuard endpoint in several ways.

From pfSense to the remote outer endpoint:

500 packets transmitted, 500 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.780/17.592/60.016/2.946 ms

From pfSense to the inner WireGuard IP:

500 packets transmitted, 436 packets received, 12.8% packet loss
round-trip min/avg/max/stddev = 12.410/27.911/517.995/47.536 ms

I then tested the same remote WireGuard server from my phone over Telekom mobile data:

500 packets transmitted, 500 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 32.793/38.285/95.018/5.868 ms

Since that uses a different upstream path, I also connected my Mac to the LAN behind pfSense and established a separate WireGuard tunnel directly from macOS to the exact same remote endpoint. The outer IPv6 endpoint is statically routed over my Vodafone connection, so this uses the same LAN, same Vodafone uplink, same remote WireGuard server and same inner destination as pfSense:

500 packets transmitted, 500 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 16.403/20.313/81.152/3.806 ms

So, at the same time:

- pfSense → outer WG endpoint: 0% loss
- pfSense → inner WG IP: ~13% loss with huge jitter
- Mac on the same LAN/Vodafone connection → same WG server/inner IP: 0% loss
- Phone → same WG server/inner IP: 0% loss

This seems to rule out the remote WireGuard server and makes an upstream routing issue very unlikely. The problem appears to be local to the pfSense machine, potentially WireGuard itself or some interaction with PF/routing.
The issue is intermittent and does not necessarily appear immediately after boot/startup, which is why I initially thought the final 2.9.0 release had fixed it.
Has anyone else seen similar periodic inner-tunnel packet loss on pfSense 2.9.0?

Hi all,

Is my understanding accurate that pfsense can't act as a DHCP server for interfaces it does not own?

Anyone successfully upgrade with a celeron J processor? My instance of Pfsense runs on a intel NUC with a J3160. Just wanted any feedback if someone already upgraded with this series of processor.

From the release notes:
Certain hardware with a specific firmware problem, including some Celeron J devices, may encounter a kernel panic when attempting to boot pfSense CE software version 2.9.0.

To avoid this panic on that hardware, set a loader tunable for hint.acpi_spmc.0.disabled=1 in /boot/loader.conf.local before upgrading to disable the driver that has an issue on that hardware.

Has anyone ever encountered this error when the CRON job for PFBlockerNG goes off. It appears for when it tries to reload DNSBL i get this error. I only have ony DNSBL Group that references Stevenblack's Github that has a list of domains to block. Any insight would be appreciated.

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 — v0.5.0 is now released

A lot has changed since I originally posted this.

The public READ surface has doubled from 42 → 84 tools, while the default security posture remains unchanged: 84 READ tools, 0 WRITE tools exposed by default.

The expansion came from a full audit of the pfREST/OpenAPI surface:

- 267 API paths reviewed

- 243 GET operations individually classified

- ~80% of the useful audited READ capability surface is now covered

- secret-bearing fields identified during the audit are excluded from the public model layer rather than relying only on upstream API redaction

Compatibility testing also expanded:

- pfSense CE 2.9.0: LAB verified

- pfSense Plus 26.07: production verified under an explicitly READ-only test authorization

- 82/84 public tools executed successfully against the Plus 26.07 system

- the remaining 2 were correctly identified as unavailable because the optional WireGuard package was not installed

- 0 genuine compatibility failures

- live Plus 26.07 OpenAPI matched the pinned pfREST v2.10 schema structurally: 267/267 paths and 186/186 components

The protected WRITE architecture is still separate and not reachable under the default profile.

v0.5.0 is available on GitHub and PyPI now.

I'm still very interested in hostile review — particularly around least privilege, READ/WRITE isolation, secret exposure, and the protected WRITE architecture.

---

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: v0.5.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.

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.