OPNsense 26.7 Migration: Source NAT, Legacy Rules, And Rollback
Tech GuruQuick Answer
Rehearse the upgrade and NAT conversion on an isolated firewall clone before changing production. Save the configuration and effective rules, then compare outbound behavior, rule ordering, WireGuard static-port cases, multi-WAN, IPv6, and captive-portal access from representative clients. Keep a tested prior-release recovery path. Final 26.7 release notes are available, but that does not establish that your legacy rules convert correctly or that your backup restores the firewall.
Evidence status: Final 26.7 release notes were checked on 2 October 2026. No ruleset diff, traffic capture, clone migration, or rollback result is supplied here. Production migration still requires those checks on the exact target build.
What To Check
The official 26.7 series notes include the final 15 July 2026 release and describe an outbound-NAT-to-source-NAT migration assistant. Release availability does not establish whether a particular firewall is ready to upgrade.
Treat the saved configuration, installed rules, and observed traffic as three separate records. The task is to explain each relevant before/after difference. A converted rule visible in the UI is not the acceptance result; the client and traffic checks below are still needed.
Key Concepts In Plain Language
- Source NAT: The source address/port translation whose ordering and static-port behavior must be compared across the migration.
- Effective rules: The rules actually loaded by the firewall, to compare with saved configuration and client observations.
- Rollback: A tested bootable prior release or supported reinstall/import path, not merely possession of an export.
Technical Checklist
- Read the final 26.7 and target point-release notes; the historical RC citation is not the authority for current migration behavior.
- Clone the firewall, export configuration and NAT state, and save effective pfctl rules before and after conversion.
- Test WireGuard static-port NAT where configured, outbound NAT ordering, multi-WAN, IPv6, captive portal, and policy routing from representative clients.
- Maintain a bootable prior release or documented reinstall-and-import path and prove it on the clone before the window.
Interactive Operating Model
The final release notes establish release availability, not migration safety. Use the target build's notes and keep the clone, effective-rule, client, and recovery checks separate.
Before You Start: Safe Defaults
Clone the firewall into a test network that cannot accidentally serve production clients. Preserve configuration, NAT data, credentials/certificates, interface assignments, and direct console access. Choose the exact source and target builds and keep compatible recovery media and a pre-upgrade export available.
- Confirm the exact installed release, edition, repository, firmware, and add-on state instead of relying on the dashboard label alone.
- Export configuration and protect application data, credentials, certificates, and encryption material separately.
- Stage on a clone, spare node, canary device, or least-critical workload whenever the platform allows it.
- Define stop conditions and console access before the maintenance window begins.
Go, Hold, Recover, Or Escalate
Hold migration if any NAT difference, management route, plugin dependency, or prior-release recovery step is unexplained. Final-release availability does not waive the clone and rollback tests. Escalate if service cannot be kept safe during the rehearsal.
Planned Checks And Recovery
Step 1: Capture the working firewall
Record interfaces, versions, plugins, routes, NAT rules, and the user flows that depend on them. Save the effective pfctl rules using the supported inspection procedure for that release. Do not flush or replace the running rules merely to obtain a baseline; exact command syntax remains to be verified for the target.
Step 2: Rehearse recovery on the clone
Demonstrate that the saved prior-release state can be booted or reinstalled and imported in isolation. Verify console and management access plus a representative client transaction. Keep that known-working export distinct from any configuration produced by the upgrade.
Step 3: Convert and compare
Follow the final migration guidance for the selected build. Compare the converted source NAT rules with the old outbound NAT ordering, interface selections, and configured static-port behavior. Keep both effective rulesets and explain each difference before testing wider traffic.
Step 4: Test each network feature in use
Use the same client/destination pairs before and after conversion. For configured WireGuard/static-port cases, compare the expected and observed translation; do not infer a universal WireGuard static-port requirement. Exercise policy routes, WAN failover, IPv6 access, and captive-portal authorized/unauthorized cases separately. Record captures and timestamps without exposing credentials or unrelated traffic.
Step 5: Roll back and retest
Return the clone through the rehearsed recovery path. Repeat management, NAT, client, and alert checks. A restored UI alone is not enough. Schedule production only when the intended build and ruleset pass the required flows and the recovery path is repeatable.
Validation Checklist
- The exact source/target builds, final migration notes, and pre-upgrade export are identified.
- Saved and effective NAT rules have an explained before/after comparison, including static-port behavior where used.
- WireGuard, multi-WAN, policy routing, IPv6, and captive portal have separate results or a justified not-applicable entry.
- The clone returns to its pre-upgrade service state; management access, denied traffic, and independent alert delivery are checked.
Troubleshooting
- The UI looks correct but traffic changes: Compare loaded rule order, selected interface, translation, and the observed client flow.
- Only one WAN or client fails: Compare its policy route, NAT mapping, and return path with the successful case before widening a rule.
- Prior-release recovery fails: Verify the preserved pre-upgrade export, compatible media, interface mapping, and required trust material.
Security, Privacy, Legal, And Recovery Boundaries
Security
Use official packages and release guidance, preserve signing and authentication controls, and do not expose a management plane to simplify migration.
Privacy
Configuration exports and support bundles may contain names, addresses, tokens, certificates, device identifiers, and user data; encrypt and restrict them.
Legal
Review software licenses, support entitlements, and retention obligations before copying production data into a test environment.
Recovery
A rollback is credible only when its media, configuration, keys, data, boot path, and restore order are available outside the system being changed.
Record any local exception, its owner, its expiration condition, and the evidence required to remove it.
What The Evidence Does Not Prove
The final release record does not prove migration correctness, plugin compatibility, packet-filter behavior, or rollback on your appliance. No traffic tests were performed. The historical RC source remains linked for context; use final and point-release notes for the operational decision.
Related TechGeeks Resources
- Linux and Homelab Notes: Start Here
- Homelab Backup Strategy: NAS, Offsite Copies, and Restore Tests
- How Do You Document a Homelab So Someone Else Can Recover It?
References
Next Action
Approve the migration from the ruleset comparison and client/recovery results, not from the release label or a successful configuration import.
