Daniel sent us this one — and I think it's going to resonate with anyone who's ever stared at an OPNsense firewall page and realized they're just clicking buttons without knowing what actually happens under the hood. He's asking about two things: what configuring manual outbound NAT rules actually does at the packet level, and how much of a real latency penalty double NAT actually incurs. Not the forum mythology, not the Reddit conventional wisdom — the measurable reality.
This is the kind of question where the gap between "it works" and "I understand it" is enormous. And it's getting more relevant by the day. The homelab and pro-sumer space has exploded — people are running OPNsense or pfSense boxes, multi-WAN setups, VLAN-segmented networks — and manual NAT misconfiguration and accidental double NAT are consistently the top two support pain points across every forum.
Yet every guide basically says "set it to hybrid and move on.
Which works, mechanically — but it leaves people with no mental model for what they've actually done. So when something breaks, they're completely lost. Daniel's question is basically: can we fix that gap?
Let's start by defining exactly what we mean. When we say "manual outbound NAT," we're talking about taking control of source NAT decisions on your firewall — deciding which source IP your traffic presents to the internet. And double NAT is the condition where your firewall performs NAT on traffic that's already been NAT'd by an upstream device. Think ISP modem-router combo that claims to be in bridge mode but absolutely isn't.
The bridge mode lie is practically a genre at this point. But before we get to double NAT, let me frame what this episode is and isn't. This is a mechanisms-and-measurement episode. We're going to trace what happens at the packet level when you flip from automatic to manual NAT in OPNsense, and we're going to look at actual benchmark data on double NAT latency. This is not a step-by-step config walkthrough. We're assuming you know what NAT is at a high level — a private IP like 192.10 can't route on the public internet and needs to be translated.
If you need the NAT 101, there are a thousand YouTube videos for that. What we're doing here is the why and the how much. Why does manual NAT break things when you first enable it? What's actually different between automatic, manual, and hybrid modes? And when people blame double NAT for their lag spikes, what does the data actually show?
Who should care? Anyone running OPNsense, pfSense, or any similar firewall platform with non-trivial routing. If you've got a single flat network behind an ISP router, this episode might be interesting but it's not your daily reality. If you've got VLANs, multiple WAN connections, or you're self-hosting services — this is your life.
The stakes here aren't academic either. Misconfigured NAT breaks real things. Peer-to-peer gaming lobbies fail. VoIP calls get one-way audio. Self-hosted services become unreachable. And the double NAT latency question — people chase single-digit millisecond improvements while ignoring bufferbloat costing them a hundred milliseconds. We're going to quantify all of that.
With that framing in place, let's open the hood on OPNsense and trace exactly what happens when a packet hits a manual NAT rule versus an automatic one.
Walk me through the automatic mode first. What's OPNsense actually doing when you leave it on the default?
In automatic mode — and this is OPNsense 24.7 behavior specifically — the system generates one outbound NAT rule per interface plus subnet combination. It looks at each of your internal interfaces, checks what subnets are configured on them, and creates a rule that says: traffic from this subnet, exiting through the WAN interface, gets its source address translated to the WAN interface's IP address. Clean, simple, works for probably eighty percent of single-WAN setups.
The rule is essentially "make everything look like it came from the WAN IP.
The source NAT decision is completely automated. The firewall sees a packet from 192.10 headed to the internet, consults its automatic rule table, and rewrites the source to your public IP. The return traffic comes back to that public IP, the firewall reverses the translation, and the packet lands back at 192.It's stateful — the connection tracking table remembers the mapping.
When does automatic mode fail?
The classic failure is multi-WAN. If you've got two internet connections — say a primary fiber link and a backup LTE connection — automatic mode doesn't know which WAN interface to bind specific traffic to. It generates rules for both, but the routing decision and the NAT decision can get out of sync. Traffic might route out WAN two but get NAT'd to WAN one's IP. The return traffic comes back to the wrong interface and gets dropped.
That's where manual mode comes in.
When you switch to manual outbound NAT mode, you're telling OPNsense: I will define every single source NAT rule myself. The automatic rule generation stops completely. If you don't create a rule for a subnet, traffic from that subnet simply never gets translated — and because private IPs can't route on the public internet, those packets are effectively black-holed.
Which is why the number one "why can't I reach the internet from my IoT VLAN" post on every forum traces back to someone switching to manual mode and forgetting to create a rule for the new VLAN they added last week.
That's the trap. Manual mode gives you total control, and total control means total responsibility. There's no safety net. The packet arrives at the WAN interface with a 192.168 source address, the next hop router sees it, and — dropped. Not even logged by default, which makes troubleshooting a nightmare.
What does a manual rule actually specify at the packet level?
Let's trace a concrete example. You've got a LAN client at 192.10 sending a packet to some server on the internet. The packet arrives at your OPNsense firewall with source IP 192.The firewall consults the outbound NAT rule table — and in manual mode, it's only your rules. A typical manual rule says: traffic from source 192.0/24, exiting interface WAN, translate the source to the WAN address. The firewall rewrites the source IP in the packet header from 192.10 to your public IP, adjusts the checksum, and sends it out. The return packet comes back addressed to your public IP. The firewall looks up the connection in its state table, finds the original mapping, rewrites the destination back to 192.10, and forwards it to the LAN interface. All of this happens per packet, in kernel space, extremely fast — we're talking microseconds of processing overhead.
The real power of manual rules is the ability to pin specific traffic to specific WAN IPs.
That's the killer feature. If you've got a multi-WAN setup, you can create a manual rule that says: traffic from the VoIP VLAN, source 192.0/24, always gets NAT'd to the IP of WAN two. Traffic from the general LAN goes out WAN one. This is policy routing at the NAT layer, and it's essential for anything where source IP consistency matters — SIP trunking, certain VPN configurations, services that whitelist by IP.
Then there's the static port option.
Static port is one of those settings that sounds obscure until it bites you. By default, when OPNsense performs source NAT, it not only rewrites the source IP — it also rewrites the source port. This is called port address translation. The firewall assigns a random high-numbered port from its pool. For most protocols, this is fine. The server doesn't care what source port the client used. But some protocols embed the source port in the application-layer data. FTP in active mode is the classic example — the client sends a PORT command containing its source port, and the server connects back to that port. If the firewall has rewritten the port, the PORT command contains the wrong number, and the data connection fails. SIP has the same problem — the SIP headers contain the source port for the media stream, and if NAT changes it without the application layer knowing, you get one-way audio. Static port tells the firewall: rewrite the source IP but leave the source port alone.
Then there's hybrid mode, which is what Daniel was hinting at — the "just set it to hybrid" advice.
Hybrid mode is the sensible middle ground. It keeps all the automatic rules OPNsense would normally generate, but it lets you insert manual rules that get evaluated first. The rule evaluation order is: manual rules at the top, then automatic rules as a fallback. If a packet matches one of your manual rules, that rule is applied and the automatic rules are never consulted. If no manual rule matches, the automatic rules catch it.
It's a safety net with override capability.
It prevents the black-hole problem. You can create a manual rule for your VoIP VLAN that pins traffic to a specific WAN IP with static port, and everything else falls through to the automatic rules and works exactly as it did before. This is why every guide recommends starting with hybrid — it's the configuration that's hardest to shoot yourself in the foot with.
The failure mode people hit is switching straight to manual because it sounds more professional, then wondering why half their network went dark.
The OPNsense docs are actually explicit about this. The rule ordering is documented — manual rules are evaluated top to bottom, first match wins, then automatic rules if nothing matched. But people skip the docs, flip the mode dropdown, and panic.
I want to dig into one more thing on the mechanism side. When the firewall processes a packet through a NAT rule, is this happening before or after the routing decision?
On OPNsense, which uses pf under the hood, outbound NAT happens after the routing decision. The packet arrives, the firewall determines which interface it's going to exit based on the routing table, and then the NAT rules for that interface are evaluated. This is why the outbound NAT rules are interface-specific — the rule only applies to traffic that has already been routed to that interface.
Which is why you can't fix a routing problem with a NAT rule.
If your traffic is routing out the wrong WAN interface, no amount of NAT rule tweaking will fix it. You need to fix the routing — policy-based routing, gateway groups, whatever. NAT just handles the source address translation after the routing decision is made. This distinction trips people up constantly.
That's the mechanism side. Manual NAT gives you control over source IP selection and port behavior, hybrid mode gives you that control with a safety net, and automatic mode works until you have multiple WAN connections or protocols that embed port information.
Now let's talk about the cost of getting it wrong — specifically, what double NAT actually does to your latency and connection stability. Because this is where the forum mythology gets really detached from the measurements.
Let's define double NAT precisely. Double NAT happens when your OPNsense firewall's WAN interface receives an IP address that's already been translated once — meaning the device upstream of you already performed NAT on that traffic before handing it off. The classic scenario: your ISP gave you a modem-router combo, you plugged your own firewall into one of its LAN ports, and now both devices are doing NAT.
The "bridge mode" checkbox on the ISP router that doesn't actually bridge anything. The ISP router's WAN interface has the public IP. Its LAN interface is handing out 192.Your OPNsense box gets 192.2 on its WAN interface, then creates its own 192.x network behind it. A packet from your LAN client goes through two translation hops before it ever sees the public internet. Source address gets rewritten twice, connection state gets tracked twice, and return traffic has to be untangled twice.
The question Daniel's really asking is: how much does that second translation actually cost?
The answer is more interesting than most people expect. There are benchmarks on this — tests from 2024 through this year comparing single NAT versus double NAT. The per-packet processing overhead under light load — think web browsing, email, streaming — is between zero point three and one point five milliseconds.
That's basically noise.
For most workloads, yes. Under heavy concurrent connection loads — torrent swarms, gaming with simultaneous VoIP, anything hammering thousands of connections — the penalty climbs to about five to eight milliseconds. Measurable, but still not the kind of thing that explains someone screaming about hundred-millisecond lag spikes in their game.
What actually explains those spikes? Because they're real — people aren't imagining them.
Connection tracking exhaustion. This is the real penalty of double NAT, and it's almost never what people are talking about when they blame "double NAT latency." Every device performing NAT maintains a connection tracking table — conntrack — that maps internal IP-port pairs to external ones. Your OPNsense box has one. The upstream ISP router has another. And here's the problem: consumer ISP combo routers typically have conntrack tables capped at four thousand to eight thousand entries.
Which sounds like a lot until you do the math.
It evaporates fast. A typical home today — twenty IoT devices, two gaming PCs, four smartphones — can easily generate eight thousand plus concurrent connections. Every smart speaker phoning home, every background app update, every browser tab keeping connections alive. When the upstream router's conntrack table fills up, it starts dropping new connection attempts silently. No RST packet, no ICMP unreachable — just a SYN that disappears into the void.
From the user's perspective, that looks exactly like lag.
Worse — it looks like intermittent failure. A website doesn't load, you refresh, it works. A game stutters for two seconds, then recovers. VoIP drops a syllable. These aren't consistent latency increases, they're random drop events, and they're maddening to troubleshoot because they don't reproduce reliably.
Whereas a consistent five millisecond penalty from the extra NAT hop would be completely invisible.
The conntrack exhaustion problem is the hidden cost. And it gets worse because double NAT means two separate conntrack tables that don't coordinate. The upstream router has no idea which connections your OPNsense box actually cares about. It's making eviction decisions blindly — and it might drop the connection your game is using while preserving the one your smart thermostat opened three hours ago.
The latency myth has a kernel of truth wrapped in the wrong diagnosis.
There's a knock-on effect that matters even more for some use cases. UPnP and NAT-PMP break completely across a double NAT boundary. These protocols let applications request automatic port forwarding — your game console asks the router to open port 3074 so it can host a lobby. But with double NAT, the request hits your OPNsense box, which opens the port — but the upstream ISP router has no idea any of this happened.
The port is open on your firewall but still blocked at the ISP router.
There's no mechanism for the request to propagate upstream. UPnP is designed for a single NAT boundary. So automatic port forwarding just silently fails. Consoles report "moderate NAT" or "strict NAT," peer-to-peer games can't establish connections, and the user has no idea why.
Which forces manual port forwarding on both devices.
A configuration nightmare. You have to log into the ISP router, set up a port forward to your OPNsense WAN IP, then log into OPNsense and set up a second port forward to the actual internal client. And if either device's IP changes — which happens constantly with DHCP — everything breaks. It's fragile in a way that single NAT setups never are.
When is double NAT actually acceptable? Because plenty of people are running it without noticing.
One, if your upstream device is in true bridge mode — modem only, no routing, no NAT — there is no double NAT. That's the ideal. Two, if you can't get bridge mode because your ISP locks it down — common with TV or VoIP bundles where the ISP router needs to manage its own services — the workaround is putting your OPNsense box in the ISP router's DMZ.
DMZ doesn't eliminate double NAT.
It doesn't, and this is a critical misconception. DMZ mode on a consumer router means "forward all unsolicited inbound traffic to this internal IP." The ISP router still performs NAT on outbound traffic. Your OPNsense WAN interface still gets a private IP. Double NAT persists. What DMZ does is fix the inbound problem — port forwards on your OPNsense box will actually work because unsolicited traffic from the internet gets passed through to you.
DMZ solves the port forwarding nightmare but not the conntrack exhaustion.
The upstream router is still tracking every connection. Its table can still fill up. DMZ is damage mitigation, not a cure. The only real cure is bridge mode, or getting your ISP to assign you a static public IP. That often forces them to configure true bridging because they can't do NAT with a static public IP on your device without breaking things.
If you're already in RFC 1918 space on your WAN interface, you know you're double NAT'd.
That's the definitive test. Open your OPNsense dashboard, look at the WAN IP. If it starts with ten dot, or 192.168, or 172.16 through 172.31 — you're behind another NAT device. No ambiguity, no guessing. Those are private address ranges by definition. The dashboard literally color-codes private IPs differently, but people still miss it. They'll spend hours troubleshooting "why is my port forward not working" without ever checking whether their WAN IP starts with ten dot.
We've established that double NAT's real penalty is connection tracking collapse, not a latency tax. But I want to circle back to something you mentioned earlier about hybrid mode — the rule evaluation order. You said manual rules are evaluated first, then automatic. Is that strictly top-to-bottom within the manual set?
And this matters more than people realize. OPNsense evaluates manual outbound NAT rules in strict top-to-bottom order — first match wins. The moment a packet matches a rule, that translation is applied and no further rules are checked. If you've got a broad rule at the top that matches everything, nothing below it ever fires.
Ordering is policy.
Ordering is absolutely policy. The classic mistake is creating a catch-all manual rule — "NAT everything from LAN to WAN address" — and placing it above a more specific rule for your VoIP subnet. The specific rule never matches because the broad rule already grabbed the packet. You get no errors, no warnings, just silent misbehavior.
Which brings us back to the "why does manual mode break things" question. The answer isn't that manual mode is buggy — it's that people don't realize they've inherited the entire rule ordering problem the moment they flip that switch.
The OPNsense docs are actually quite clear about this if you read them. They explicitly state that manual rules are evaluated first, then automatic rules as fallback in hybrid mode, and that in pure manual mode there is no fallback at all. The documentation even includes a diagram of the packet flow through the NAT subsystem — it hits the outbound NAT rules after routing, after firewall rules, right before it exits the interface.
If you're troubleshooting a NAT issue, the order of operations is: check routing first, then firewall rules, then NAT rules. In that sequence.
Because each layer depends on the one before it. A packet that's routed incorrectly never reaches the right NAT rule. A packet blocked by a firewall rule never gets NAT'd at all — it's dropped before NAT processing. This is why tcpdump on the WAN interface is the ultimate diagnostic tool. If you see packets leaving with a private source IP, your NAT rule isn't matching. If you see no packets at all, the problem is upstream — routing or firewall.
One thing we haven't touched on is the static port tradeoff. You explained why it matters for FTP and SIP, but what's the downside of just enabling it everywhere?
The downside is port collision risk. When OPNsense does port address translation — rewriting the source port randomly — it's using a pool of roughly sixty thousand ephemeral ports. The randomization makes collisions between two internal clients using the same source port extremely unlikely. If you disable port randomization with static port, and two internal clients both happen to use source port 5060 for SIP traffic, the firewall has a problem. The second connection attempt fails — or worse, the firewall rewrites it to a different port, which breaks the SIP signaling anyway. This is why the best practice is to use static port surgically — only on the specific rules where it's needed, for the specific subnets and destination ports where the protocol embeds port information.
The manual rule for SIP traffic would specify source subnet, destination port 5060, and static port enabled. Everything else falls through to automatic rules with normal port randomization.
That's the clean approach. And this is where hybrid mode really shines — you can add that one surgical rule without touching anything else.
There's another failure pattern worth mentioning that I see constantly. Someone sets up a new VLAN — say VLAN 30 for guest Wi-Fi, subnet 192.0/24 — configures DHCP, firewall rules, everything looks right, but no internet access. And the culprit is always the same thing.
No outbound NAT rule for the new subnet. In automatic mode, OPNsense would have generated one automatically. In hybrid mode, same thing — the automatic fallback catches it. But in pure manual mode, that subnet is invisible to the NAT system until you explicitly create a rule. The packet hits the routing table, gets routed to the WAN interface, then the NAT subsystem looks for a matching rule, finds nothing, and drops it.
The traffic just... No ICMP error, no log entry by default.
This is the number one "why can't my IoT VLAN reach the internet" post on the OPNsense forum. It's so common it should be a sticky. The fix is trivial once you know to look for it — add a manual outbound NAT rule for the new subnet — but the diagnosis is brutal because nothing logs the drop. The firewall says "this packet is allowed," forwards it toward the WAN interface, and then the NAT engine says "I have no translation rule for this source" and drops it. Two different subsystems, two different logging configurations. It's a gap in the diagnostic surface that's caught a lot of people.
The practical takeaway for anyone setting up OPNsense today is: start in hybrid mode, create manual rules only for the traffic that needs specific treatment, and check your WAN IP before you do anything else — because if it's in RFC 1918 space, you've got bigger problems than NAT rule ordering.
Let's turn that into a practical checklist you can use tonight.
First thing — before you touch a single NAT rule — check your WAN IP. If it's in RFC 1918 space, you're double NAT'd. That's ten dot anything, 192.168 dot anything, or 172.16 through 172.No exceptions, no edge cases.
If you are double NAT'd, the fix order is: bridge mode first, DMZ second, static public IP request third. True bridge mode on the ISP router eliminates double NAT entirely — the modem passes the public IP straight through to your OPNsense box, no translation layer. But a lot of ISPs lock bridge mode behind a phone call or bury it in a hidden config page.
Some don't offer it at all.
If you've got an ISP that provisions TV or VoIP through the same router, they often refuse to enable bridge mode because their services depend on the router's internal routing. In that case, DMZ mode pointed at your OPNsense WAN IP is the workaround. It doesn't remove double NAT — the upstream router still translates outbound traffic — but it solves the inbound port forwarding problem. Unsolicited traffic from the internet gets passed through to your firewall instead of being dropped at the ISP router.
As a last resort, requesting a static public IP from your ISP sometimes forces their hand. They often can't do carrier-grade NAT with a static assignment, so they'll configure true bridging to make it work.
Now, once you've confirmed you're not double NAT'd — or you've accepted that you are and mitigated it — the actual NAT mode configuration is straightforward. Start with hybrid. It keeps the automatic rules as a safety net and lets you add manual overrides for the traffic that needs specific treatment.
What traffic actually needs manual rules?
One, multi-WAN policy routing — you need traffic from specific subnets pinned to specific WAN IPs. Two, protocols that embed source port information in their application data — SIP, FTP active mode, some older VPN protocols. Those need static port enabled on the rule. Three, any scenario where you need a specific source IP presented to a remote service for whitelisting purposes.
For everything else, the automatic rules are fine.
Better than fine — they handle port randomization properly, which avoids the collision risk we talked about. The moment you start enabling static port on broad rules, you're inviting problems.
Once you've created your manual rules, verify them. Don't assume they're working because the internet "feels fine." Run tcpdump on the WAN interface and confirm that traffic is exiting with the source IP you expect. If you see packets leaving with a private source address, your NAT rule isn't matching.
That diagnostic flow — check routing, then firewall rules, then NAT rules, in that order — will catch almost everything. Most "NAT problems" are actually routing or firewall problems that manifest at the NAT layer.
The latency myth is worth busting explicitly here. If you're chasing single-digit millisecond improvements by eliminating double NAT while your Wi-Fi is adding fifty milliseconds of jitter, you're optimizing the wrong thing. Fix bufferbloat first. Fix your wireless environment. Double NAT optimization is the final five percent polish for people who've already solved everything else.
The thing you'll actually feel isn't the consistent sub-two-millisecond penalty — it's the connection tracking exhaustion causing intermittent drops. If you're seeing random timeouts that resolve on retry, check your upstream router's conntrack table. If it's pegged at its maximum, that's your problem, not "double NAT latency.
There's one more thing worth flagging. UPnP and NAT-PMP aren't coming back across a double NAT boundary. If you're double NAT'd and you rely on automatic port forwarding for gaming consoles or P2P applications, you have two choices: manual port forwards on both devices, or eliminate the double NAT. There's no third option.
That checklist — check your WAN IP, start with hybrid, add surgical manual rules for SIP and multi-WAN, verify with tcpdump — that's the ninety percent solution. You can do all of that in fifteen minutes.
The one thing I'd add: after you switch to hybrid mode and add your manual rules, reboot something. A switch, a client, the firewall itself — just introduce a state change and watch what happens. A lot of NAT misconfigurations only surface when connections get rebuilt from scratch.
That's a clinical instinct right there. In medicine you always test the system under stress, not at rest. A NAT table that looks perfect at idle can fall apart the moment a torrent client opens three thousand connections.
If you're already double NAT'd and can't fix it — ISP won't bridge, DMZ is the best you've got — there's one more diagnostic worth running. Check your upstream router's conntrack maximum. Most consumer units expose it somewhere in the admin page, usually under status or diagnostics. If it's sitting at four thousand ninety six entries and your household is pushing eight thousand connections, you've found your intermittent failure.
Some routers let you increase that limit. Not all, but it's worth looking. Even bumping it to sixteen thousand can buy you breathing room. It doesn't fix the double NAT, but it delays the exhaustion collapse.
The collapse is what people actually experience. Not a steady latency penalty — a sudden, silent drop that looks exactly like a lag spike and vanishes on retry. That's the signature of conntrack exhaustion, and once you know to look for it, it's unmistakable.
The tragedy is how many people will spend hours tuning bufferbloat settings or replacing Ethernet cables chasing a problem that's happening inside a router they forgot existed. The ISP combo unit sitting in the corner, blinking quietly, running a conntrack table that filled up six months ago and has been dropping connections ever since.
Those steps will get you ninety percent of the way. But there's one bigger question looming over all of this. As ISPs keep running out of IPv4 addresses, carrier-grade NAT is becoming the default for more and more users. CGNAT means you're behind the ISP's own NAT layer before you even plug in your own router. Double NAT becomes triple NAT. And there's no bridge mode escape hatch — the ISP owns that translation layer and you can't touch it.
This is where the IPv6 people say "I told you so." And honestly, they've got a point. IPv6 eliminates the entire address scarcity problem that NAT was invented to solve. Every device gets a globally routable address. No translation, no conntrack exhaustion, no port forwarding nightmares. The NAT layer just...
We've been hearing that for twenty years.
Adoption is actually moving now. Major ISPs are deploying IPv6, mobile networks have been IPv6-native for years, and OPNsense handles it cleanly. But the transition isn't binary. Most networks run dual-stack — IPv4 and IPv6 side by side — and the IPv4 traffic still goes through NAT. So even if you deploy IPv6 tomorrow, you're still managing NAT rules for the foreseeable future.
What are the viable IPv4 workarounds when CGNAT makes bridge mode impossible?
Tunneling is the practical answer. You can rent a cheap VPS with a public IPv4 address, set up a WireGuard or OpenVPN tunnel from your OPNsense box to that VPS, and route your inbound traffic through the tunnel. The VPS becomes your public-facing endpoint, and your home network gets a stable public presence without needing the ISP to cooperate.
Which sounds like a fun weekend project and a recurring eleven-dollar monthly charge.
That's the tradeoff. It's not free, and it adds a hop — your traffic routes through the VPS, so latency depends on the datacenter location. But it solves the inbound port forwarding problem completely, and it avoids conntrack exhaustion on the ISP's CGNAT box because your tunnel looks like a single long-lived connection.
The other thing worth watching is what OPNsense itself is doing. x releases are expected to improve NAT rule diagnostics — better logging, better visualization of which rule matched which packet, maybe even warnings when you've got an interface with no NAT rule coverage.
That diagnostic gap we talked about — the silent NAT drops that don't appear in any log — that's the kind of thing where tooling improvements make a real difference. When the firewall can tell you "I dropped this packet because no outbound NAT rule matched," you go from guessing to knowing in thirty seconds.
The underlying mechanics won't change. NAT is NAT. The packet comes in, the rule table gets consulted, the source address gets rewritten. Understanding that flow is a skill that transfers to any firewall platform — pfSense, MikroTik, Cisco, whatever.
It's like learning archery. The bow changes, the sight changes, but the fundamentals of release and follow-through don't. Once you understand what a NAT rule is actually doing at the packet level, you can walk up to any firewall and figure it out.
Here's the challenge. Right now, after this episode, open your OPNsense NAT rules page. If you're sitting on automatic mode, switch to hybrid. Add one manual rule for a specific VLAN — something non-critical, your guest network or IoT subnet. Watch what happens. See if anything breaks.
If something does break, you now know exactly where to look.
That's the only way this stuff actually sticks. You can listen to us talk about NAT rule evaluation order for an hour, but until you create a rule in the wrong position and watch your traffic vanish, it's all theoretical.
The nice thing about hybrid mode is that you can always delete the manual rule and you're right back to where you started. The safety net is still there.
Which brings us to the forward-looking question I want to leave hanging. If CGNAT becomes universal for IPv4 and IPv6 adoption keeps crawling along, are we heading toward a world where running your own firewall with full control over NAT is a luxury? Something only people with business-grade ISP connections can do?
That's a genuinely uncomfortable question. The trend line isn't great. ISPs have every incentive to lock down their equipment and treat customers as endpoints rather than network operators. The homelab community has been fighting that trend for years, but CGNAT makes it structurally harder.
Something to watch. And in the meantime, understand your NAT rules. It's one of those skills that pays rent every time something breaks.
Now: Hilbert's daily fun fact.
Hilbert: In the 1840s, a prominent French cartographer argued that the Gobi Desert was once a vast inland sea, based on what he believed were ancient shoreline deposits — a theory that shaped European maps of Central Asia for decades before geologists realized the formations were wind-eroded sandstone, not seabeds.
A guy looked at some rocks, imagined an ocean, and mapmakers just... went with it.
That's terrifying.
This has been My Weird Prompts. Our producer is Hilbert Flumingtop. If you want to send us a question like Daniel did, email the show at show at my weird prompts dot com.
We'll be back next week. Go break something in hybrid mode.
