Remote Embedded Firewall Configuration Without Locking Yourself Out

The Scenario

You need to tighten the firewall on a device at a site three hours away. There is no one on-site who can reach the console, and the building runs on the network you are about to change.

These are the failure modes that bring technicians to this problem:

• The session died mid-command. You pasted a ruleset, the terminal froze, and the device stopped answering. The new rules dropped the very path you were working over.
• The device came back wrong after a reboot. Rules that worked in memory were never persisted, or a bad ruleset was persisted and now survives every restart.
• BACnet discovery stopped working after segmentation. Unicast reads to known devices still succeed, but Who-Is finds nothing. Broadcast handling is the usual cause.
• Polls time out intermittently. Modbus TCP or BACnet traffic works for a while, then stalls, then recovers — a signature of state timeouts rather than a missing rule.
• The rule looks right but traffic still drops. The rule exists in the table but sits below a broader deny, and first match wins.

What "Embedded Firewall" Actually Means

The term covers three fairly different things, and the safe procedure depends on which one you have in front of you.

• A full netfilter stack on embedded Linux. Most CPE devices and edge routers run a Linux kernel with either iptables or nftables underneath. OpenWrt-derived firmware is the common case: builds from 22.03.0 onward default to fw4, which renders the UCI firewall config into nftables rules, while earlier builds used the iptables-based fw3. The UCI syntax is largely the same across both, so the config file you are reading does not tell you which engine is running — check the device.
• A vendor web UI rule table. An ordered list of allow/deny rows with no shell access. Simpler to reason about, but most of these UIs apply changes immediately and offer no rollback.
• A controller's own IP access list. Supervisory controllers, BACnet routers, and protocol gateways frequently expose a short allow-list of peer addresses rather than a general firewall. Limited, but it is still a filter that can lock you out.

The goal in all three cases is default-deny: the device permits the flows the site needs and drops everything else. In IEC 62443 terms, this device is enforcing a conduit — the controlled communication path between two security zones. Our IEC 62443 security zones guide covers how to decide where those zone boundaries belong before you start writing rules at one.

The Safe Remote Change Procedure

Step 1: Inventory the Flows Before You Write a Rule

A default-deny ruleset written from memory will break something. Write down every flow the site depends on first, including the path you are connected over right now.

For the BACnet side specifically — broadcast handling, BBMD interaction, and which directions actually need to be open — our BACnet firewall rules guide has the detail this table compresses.

Step 2: Read the Default Policy, Not Just the Rules

Almost every implementation is first-match-wins with an implicit final action. The rules you can see are rarely what breaks the site; the policy at the bottom of the chain is.

Before changing anything, record the current ruleset and the current default policy somewhere off the device. On a netfilter box, an iptables-save or nft list ruleset dump is your rollback artifact. On a web UI, a config backup or a screenshot of the rule table is the equivalent.

Step 3: Never Apply Without a Dead-Man Rollback

This is the step that separates a routine change from a truck roll. Every remote firewall change needs a mechanism that restores the last-good state if you stop responding — because if you lock yourself out, you cannot be the one to fix it.

• iptables-apply. Ships with iptables. It applies a rules file, then prompts for confirmation, and rolls back to the previous ruleset if you do not answer before the timeout — 10 seconds by default, adjustable with -t. If the new rules cut your session, you cannot answer, so the rollback fires on its own. Raise the timeout to something realistic for the change you are testing.
• A scheduled revert. Where no purpose-built tool exists, schedule the restore before you apply the change: queue a job that reloads the saved ruleset in ten minutes, make your change, verify, then cancel the job. The discipline is the same — the rollback is armed before the risk is taken.
• nftables atomic replacement. nftables applies a ruleset file in a single transaction, so the device never sits in a half-applied state. That protects you from partial rulesets; it does not protect you from a complete ruleset that is wrong. You still need the timed revert.
• The vendor's confirm timer. Some web UIs offer an "apply provisionally, confirm within N minutes" option. Use it when it exists.
• Reboot as a fallback. If the device has no rollback mechanism at all, work only in the running config and leave the change unpersisted. A scheduled reboot then returns the device to the last-good saved ruleset.

Step 4: Verify From the Real Source Address

Test from where production traffic actually originates. A rule verified from a laptop on the site LAN proves nothing about a technician arriving through an encrypted tunnel, because the source address the firewall sees is different.

Check both directions and both outcomes: the flows you intended to permit still pass, and the flows you intended to block are actually blocked. A change that only proves the first half has not been tested.

Step 5: Persist Only After Verification

Save the ruleset once the change is confirmed, then reboot the device during a maintenance window and confirm it comes back with the rules you expect. An unverified persisted ruleset is worse than no ruleset — it survives the reboot that would otherwise have rescued you.

Common Pitfalls

• Assuming stateful rules cover BACnet. A generic "allow established and related, drop everything else" ruleset handles TCP well and misleads badly on BACnet. Connection tracking does create state for UDP flows, but only unicast exchanges produce state you can use: a ReadProperty reply from device:47808 back to supervisor:47808 inverts the original tuple exactly, which is why unicast reads keep working. Discovery produces no usable state in either direction. A Who-Is goes to the subnet broadcast address, so the conntrack entry is supervisor:47808 → 10.1.10.255:47808 and the only reply that matches it would have to come back from the broadcast address. An I-Am from an individual device:47808 never inverts that tuple, so it is not treated as established and gets dropped — your own Who-Is/I-Am exchange fails, not just unsolicited inbound discovery. Both the outbound broadcast Who-Is and the returning I-Am need explicit rules. Discovery breaks while unicast reads keep working — which is exactly why this one takes so long to diagnose.
• Ignoring broadcast traffic. BACnet discovery depends on broadcasts, and firewall rules written around unicast host pairs silently kill it. If devices need to be found rather than just polled, the broadcast path has to be handled deliberately, whether by rule or by BBMD.
• Leaving the management plane on the WAN side. A device that accepts SSH or HTTPS administration from the WAN interface is exposed regardless of how carefully the protocol rules are written. Bind management to the tunnel or the LAN side.
• Forgetting egress. Default-deny outbound is good practice and breaks things quietly. NTP is the classic casualty: the controller keeps running, the clock drifts, and schedules start firing at the wrong time days later.
• Trusting the config file over the device. On OpenWrt-derived firmware in particular, the UCI config reads the same whether fw3 or fw4 is rendering it. Custom rules written against the wrong engine load silently and do nothing.
• Changing rules and access lists in the same window. When a controller's IP allow-list and the edge firewall both change at once, you cannot tell which one dropped the traffic. Change one, verify, then change the next.

When to Escalate

Escalate to on-site hands when the device stops answering and no rollback was armed. There is no remote recovery from a locked-out embedded firewall — that is the whole reason Step 3 exists.

Escalate to the vendor when the rules are demonstrably correct and traffic still drops. Some embedded firewalls apply hidden default rules, filter before the user-visible table, or handle broadcast in ways the documentation does not describe. Bring a capture from both sides of the device: proving the packet arrives and does not leave turns a debate into a support case.

Escalate to the network owner when the required flow list conflicts with the site's segmentation policy. That is a zone-and-conduit decision, not a firewall rule, and it should be made deliberately rather than worked around at the console.

SiteConduit takes the lockout risk out of this entirely: sessions are protocol-restricted and default-deny by design, so the flows a technician can reach are decided by policy on the platform rather than by hand-edited rules on a device at the far end of a cellular link. Secure remote access for cyber-physical systems covers the architecture.

Source Attribution

The technical guidance in this entry is informed by the following sources:

• iptables-apply(8) — Linux manual page — Normative reference for the confirmation prompt, the default 10-second timeout, and the automatic rollback behavior described in Step 3.
• OpenWrt Firewall Configuration — UCI firewall syntax and the fw3 to fw4 transition; firewall4 became the default in OpenWrt 22.03.0.
• nftables wiki — netfilter.org — Atomic ruleset replacement and the nftables rule model.
• conntrack-tools user manual — netfilter.org — Connection tracking behavior for UDP flows, which underpins the stateful-rules pitfall above.
• Niagara 4 Hardening Guide — Tridium. Fox and secure Fox port defaults and the recommendation against the plaintext Fox variant.
• ASHRAE Standard 135 — BACnet—A Data Communication Protocol for Building Automation and Control Networks. Annex J defines BACnet/IP and the UDP 47808 default; the Who-Is/I-Am broadcast mechanism is the normative basis for the discovery pitfalls above.
• Modbus Application Protocol Specification and Modbus Messaging on TCP/IP Implementation Guide — Modbus Organization. Reference for the TCP 502 default.
• IEC 62443 — Security for industrial automation and control systems. The zone-and-conduit model referenced throughout.

Additional testing and field validation by SiteConduit.