pfsense-redactor 1.1.2

Enterprise-grade tool to redact secrets and anonymise identifiers in pfSense/Netgate config.xml exports. Preserves network topology while removing passwords, VPN keys, certificates, public IPs, domains, and MACs for safe sharing with support teams, consultants, AI tools, and forums.

pfSense XML Configuration Redactor

Redact secrets from a pfSense config.xml so you can share it with Netgate support, a vendor, a forum or an AI tool, without handing over your passwords, keys and network layout.

Unlike generic XML redaction, it understands pfSense structures: IPsec, OpenVPN, WireGuard, captive portal, and the package configs where credentials actually hide.

Install

pip install pfsense-redactor

Pure Python standard library, no dependencies, Python 3.9+.

If pip reports externally-managed-environment

Common on macOS and recent Linux distributions. Any of these work:

pipx install pfsense-redactor          # recommended for CLI tools

python3 -m venv venv && source venv/bin/activate
pip install pfsense-redactor

pip install --user pfsense-redactor

From source

git clone https://github.com/grounzero/pfsense-redactor.git
cd pfsense-redactor
pip install -e .

Quick start

Sharing with support, keeping internal addressing readable:

pfsense-redactor config.xml redacted.xml --keep-private-ips

Removes secrets and public identifiers, leaves RFC 1918 addressing intact so whoever is helping can still follow your topology.

Sharing with a vendor, forum or AI tool, anonymising identifiers:

pfsense-redactor config.xml redacted.xml --anonymise

Replaces addresses and domains with consistent placeholders, so relationships between rules and interfaces survive while the real values do not.

Check before you commit to it:

pfsense-redactor config.xml --dry-run-verbose

Prints what would change, with samples safely masked.

Using an unusual package? Add --aggressive. Webhook tokens live in URL paths, and paths are otherwise preserved so package feed URLs are not destroyed. Slack, Discord and Telegram are recognised and redacted without it; anything else needs the flag. See security.

How well does it work?

Measured against a 46-secret canary corpus that ships with the repository:

Tool	Caught
pfsense-redactor	42 / 46 (43 with --redact-descriptions)
ForesightCyber Config Anonymizer	17 / 46
netgate-xlsx	11 / 46

The corpus was built alongside this tool, which biases it. The four misses are documented rather than hidden. Run it yourself:

pfsense-redactor tests/corpus/canary-corpus.xml --stdout --aggressive \
  | grep -oE 'CANARY_[A-Z0-9_]+' | sort -u

Full method, caveats and per-secret results in the benchmark.

Before you share the output

Never restore a redacted file to pfSense. Comments, CDATA and some metadata do not survive the round trip. Keep your original.

Read the run summary. It reports high-entropy values it deliberately kept, with their element paths, so you can audit them. For a second opinion from a scanner that fails differently, see verifying output.

Documentation

Guide	Covers
CLI reference	Every flag, with examples
Use cases	Netgate TAC, AI tools, MSP handoff, audits, and how this relates to diag_sanitize.php
Allow-lists	Keep specific IPs, CIDRs and domains readable
Security	Threat model, what gets redacted, path safety
Verifying output	Checking the result, and using gitleaks alongside
Benchmark	Canary corpus results and known gaps
Examples	Before/after output, statistics, testing
FAQ	Common questions
Changelog	Release history

Contributing

Issues and pull requests are welcome. If you find a secret that survives redaction, that is the most valuable report there is. A minimal fragment with the value replaced by a CANARY_* marker can go straight into the corpus so the miss stays fixed.

Run the tests with:

pip install -e ".[dev]"
pytest

Licence

MIT. See LICENSE.