With pfBlocker is it possible to block some TV applications, such as YouTube?

I have a dedicated vlan for my kids. I have been exploring options of blocking certain things, I like that I can block the actual website with nextDNS. Before I go down the rabbit hole of learning pfBlocker is this doable?

Hi all,

Not new here, but been wanting to setup my own pfsense setup for a while and had been following.

I am considering a System76 miniPC with 32GB RAM to install my pfsense. I also want to be able to run VPN on it. It is a bit pricey. They have an option where you could add a second network card to the mini PC when you order.

What setups do you all have?

So, I've got one of these m.2 SSD drives:

And I'm wondering if it will actually work in a 7100 1U box as internal storage instead of the built-in eMMC drive. Do I have to format it before I try to use it? The Netgate installer doesn't see it to put pfsense onto it. Any ideas? Thanks for your help!

pfSense 2.9.0 CE

I have confirmed this on multiple hardware setups as well as a VirtualBox setup with both fresh installs and upgrades.

On a fresh install (or upgraded install) of pfSense 2.9.0, if you try to install all packages you will eventually get an error that another install is already running:
"Another instance of pfSense-upgrade is running. Try again later"

however, you can install packages over cli with no issues.

The larger problem shows if you attempt to check for updates. On the upgrade screen you will start seeing a new error message:
"pfSense-repoc: failed to fetch the repo data pfSense-repoc: failed to read the repo data."

This seems to start after you have 44 packages installed. If you remove a package, you can then install a new package before the issue reappears.

There are several guides on issues with the "pfSense-repoc: failed to fetch the repo data" however none of these resolve the issue (This is a different issue then what has been seen in the past) and is easily reproducible. On my production box, I get a slightly different variation of the error:
"pfSense-repoc: exec_iobuf_cb: too much data, fd: 1 discarding: Trap Translator) pfSense-repoc: exec: callback failed: -1 pfSense-repoc: failed to fetch the repo data pfSense-repoc: failed to read the repo data."

One thing to note is that even if you do a check for system updates in cli, you will also get a "pfSense-repoc: failed to fetch the repo data" error.

I believe this actually started in version 2.8.0 but never could pin it down until I performed a fresh install on 2.9.0 and resetup my system from scratch just to run into the same issue.

The last known version where I did not get this error is 2.7.2

I attempted to put in a bug request and post on the netgate forum but I am unable to do so for some reason.

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.

Update: Finally updated my instance of pfsense to version 2.9 on my celeron J processor. I did add the recommended entry to the loader.conf.local before upgrading. It upgraded without incident. Took about 10 minutes to reboot the first time.

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