A firewall rule is not a network boundary

The rule that looked right on paper

There is a satisfying moment in a home-server project when a firewall rule turns red in the log and the traffic stops. It feels like a boundary has been built: trusted things on one side, untrusted things on the other, and a neat line in the interface keeping them apart.

That feeling is useful, but incomplete. A rule is a decision about traffic that reaches a particular filtering point. A network boundary is a property of the design around it: which devices share a layer-2 network, which paths are routed, what the default policy is, how exceptions are named, and how you recover when the rule is wrong.

OPNsense's own VLAN documentation makes the distinction concrete. Each VLAN is an isolated network, and traffic that crosses between them is routed and controlled by firewall rules. Devices in the same VLAN communicate directly, however, using neighbor discovery rather than asking a central firewall to inspect every exchange. If two devices should not trust one another, putting both in one segment and adding a clever rule is not the same as separating the segment in the first place.

The practical lesson is simple: design the zones before writing the rules.

Name the trust zones in plain language

Start with a small inventory, not a diagram of every device. A neutral home example might have four zones:

These labels are policy, not a claim that every house needs four networks. OPNsense's security-zone guide recommends broad zones and warns against creating too many. The point is to make a decision legible: “Guest cannot initiate connections to Services” is a sentence a person can review. “opt7 to opt12, except for three aliases and the floating rule above it” is an implementation detail that needs a second translation.

For each pair of zones, write one of three answers: allow, deny, or not yet decided. Then add the service and direction. “Home to Services” is not precise enough; “Home may reach the dashboard over HTTPS” is a testable policy.

• **Admin:** the small set of devices allowed to change infrastructure.
• **Services:** servers and appliances that provide something to other zones.
• **Home:** ordinary personal devices that need useful outbound access.
• **Guest:** devices that should reach the internet but not your private services.

Treat the default as part of the design

OPNsense documents pass, block and reject as different actions. Pass permits the match. Block drops it without telling the client. Reject tells the client that it was refused. That distinction matters operationally, but none of the three answers the larger question: what happens when no exception matches?

For an untrusted zone, a useful starting judgment is default deny, with narrow, named passes for the services that are genuinely needed. That is not a magic security guarantee. It is a way to make new access fail closed while you decide whether it belongs.

Rule order is part of the policy. OPNsense processes rules in sections and documents first-match behavior for quick rules. A broad pass above a narrow block can make the block irrelevant. A policy change may also appear not to work immediately because an existing state can continue to carry traffic; the documentation notes that states sometimes need to be reset before new policies are used by existing connections.

After every meaningful change, ask two separate questions: did a new connection take the intended path, and what happened to connections that already existed? Test both. A green rule counter is evidence of a match, not proof that the whole policy is correct.

Use names that survive the next change

Long address lists make a firewall look precise while making it hard to maintain. OPNsense aliases let you name reusable sets of networks, hosts or ports and use those names in rules. That is valuable even in a small home setup.

Prefer policy-shaped names such as `service-dashboards` or `admin-devices` in your own documentation, with descriptions that say why the group exists. Keep the list and the rule separate. When a service moves, update the alias and then test the policy; do not copy a new address into six rules and hope you found them all.

Make the evidence match the question

A failed connection and a successful connection do not prove the same thing. For each zone boundary, keep a short test table:

Enable logging selectively on rules where the evidence is useful. OPNsense's live view can identify the rule associated with a match, but its documentation also says that an existing state reports only its first packet while that state remains active. That makes “I do not see another log line” a weak conclusion. Close the client connection, create a fresh one, and use packet capture or service logs when the firewall log cannot answer the question.

Do not turn every rule into a permanent stream of sensitive traffic records. Log enough to investigate a boundary, then decide what retention and access are appropriate for your household. The evidence should explain a decision, not become a second private-data problem.

• source zone and destination zone;
• destination service and direction;
• expected result;
• observed result from a fresh connection;
• date, rule description and next action if it differs.

Keep a recovery route before you need it

The most important firewall test is not “can I apply a rule?” It is “can I get back in if I apply the wrong rule?”

Before changing access to administration, export a known-good configuration, protect the export as sensitive material, and confirm where the console or local recovery path is. OPNsense documents both configuration history and restore, and warns that partial restores can behave unexpectedly because configuration components depend on one another. A complete, known-good restore is often the safer recovery shape than trying to repair one fragment while the system is inaccessible.

Keep a second path to the appliance that does not depend on the policy you are about to change. Write down the order: save, change one thing, test from each relevant zone, and revert if the result is not what the table predicted. If you cannot name the rollback step, the change is not ready for a quiet evening.

Where this stops

Segmentation does not make an unpatched service safe, prove that a device is trustworthy, or stop a user from carrying data from one zone to another. A firewall sees the paths and protocols it can observe; it does not understand the full meaning of every application request. Same-segment traffic can also bypass the central routed boundary, which is why placement matters.

What we would do next is choose one boundary and write its four-line contract: who may initiate, what service is allowed, what evidence will confirm it, and how to restore the previous configuration. A firewall becomes easier to trust when its rules are small enough to explain and its mistakes are recoverable. A backup is not a restore plan covers the same discipline from the data side: successful protection is not the same as demonstrated recovery.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. VLAN and LAGG Setup — OPNsense. Explains that each VLAN is its own isolated network, that traffic crossing VLAN boundaries is routed and controlled by firewall rules, and that devices in the same VLAN communicate directly rather than through a central firewall.
2. Security Zones — OPNsense. Describes interface groups as trust zones, distinguishes intrazone from interzone rules, recommends broad zones, and shows that zone policies can reduce rule duplication and clarify troubleshooting.
3. Rules — OPNsense. Documents the stateful packet filter, pass/block/reject actions, processing order, first-match behavior for quick rules, the default-drop behavior, and the need to reset states after some policy changes.
4. Aliases — OPNsense. Defines aliases as named lists of networks, hosts or ports that can be reused in firewall rules, making changing access lists easier to administer and inspect.
5. Log Files — OPNsense. Documents live firewall logging, rule identification through the rid field, and the limit that an existing state reports only its first packet while the state remains active.
6. Configuration — OPNsense. Documents configuration backup and restore, advises protecting sensitive exports with a strong password, and warns that partial restores can cause unexpected behavior because components depend on one another.

More from Server Attic

• 2026-08-19

  A health check is not a recovery plan

  A practical home-server guide to separating liveness, readiness and restart signals from the human decisions that make recovery safe.

• 2026-07-18

  A backup is not a restore plan

  A practical home-server guide to turning backup jobs into evidence you can actually recover from, using restore drills, integrity checks and clear limits.

• 2026-08-28

  Automate disk cleanup only after you can explain the growth

  A full disk invites a hurried deletion. A safer home-server workflow identifies the owner, growth rate, reclaimable data, retention need and recovery path before cleanup becomes automatic.