There are only two ways to write a firewall policy: default allow, where only explicitly blocked traffic is stopped, and default deny, where only explicitly permitted traffic passes. Devices ship in the first state, because the first requirement out of the box is that things connect. Real deployments often need the opposite — a handful of devices with known vulnerabilities that must reach other machines on the LAN and one specific license server, and must not reach any other internet address. This work usually ends up in the firewall rule table of an industrial cellular router.

Default allow is not a decision, it is the absence of one

On a 4G cellular router, the traffic rules table ships with a LAN-to-WAN rule that lets LAN devices reach any internet address. A  cellular router with no rules added by anyone is running Allow All. The statement "the firewall was never turned on" describes a state, not a policy.

The hard part is not writing rules, it is inventorying traffic

Default deny needs only a few lines of rule syntax. The time goes into the inventory taken beforehand: which device (source MAC or source IP), which destination address or port, which protocol. One missing entry shows up later as a device whose function works intermittently.

Three categories cover most of what has to be listed: outbound traffic to internet addresses, lateral traffic to other machines inside the LAN, and inbound traffic for maintenance. The first is where a whitelist does the work, the second usually stays open, and the third belongs in a tunnel rather than in the rule table.

When the inventory is uncertain, split the rollout in two. Add only the permit rules first, leave the catch-all deny out, and let the cellular router run as before while the firewall log shows what traffic actually appears. Once the list is stable, append the catch-all deny. This replaces guessing at traffic relationships with observing them.

The three-part rule structure

Back to the devices that may only reach the license server:

Rule one, permit. Source address is the device IP, or switch to MAC matching. Destination address is the license server. Protocol is TCP, UDP, or both, as the application requires. Action is accept.

Rule two, deny. Source address is any, destination address is any, action is reject.

As a table, that is two rows:

The table is matched in order and stops at the first hit, so the permit rule must come first and the catch-all deny must come last. Reversing the order cuts every device off at once. Rules take effect after being saved and the device rebooted.

Two details are easy to miss. When matching on source MAC, the source IP field has to be left empty — filling it in breaks the match. And on some firmware versions the destination zone is split into separate wired and cellular entries; ticking only one leaves the rule uncovered after a link switch, so selecting the full forward zone is the simpler choice.

The same table also covers rules aimed at the  cellular router itself. The destination zone offers a device input option next to the forward option, and that is where management access gets closed off: permitted from the maintenance subnet or through the tunnel, denied from everywhere else.

Boundaries run in both directions

An outbound whitelist governs where a device may go. Inbound traffic is handled separately: remote maintenance runs entirely inside a VPN tunnel, the management interface is not exposed on the public side, port forwarding is opened one entry at a time only where required, and DMZ is switched off when unused — it maps every port of one internal device to the outside, and port forwarding and DMZ cannot run at the same time, which is another reason to leave it off.

The same firewall menu carries two more tools worth using: domain blacklists and whitelists, which keep permitted domain names in a whitelist; and rate limiting by IP range or MAC address, which keeps one device from consuming the whole cellular data allowance.

What to check when selecting hardware

Whether an industrial  cellular router can carry default deny depends first on rule granularity — source MAC, source IP, port, protocol — and second on whether rule order can be adjusted. Those two properties decide whether the policy can be built at all.

On interfaces, the USR-G806w offers three Ethernet ports, one WAN plus two LAN, configurable as three LAN, so up to four devices can connect directly without an extra switch. Cellular is the primary uplink, with wired, cellular and Wi-Fi access modes able to switch freely and service recovering when a link fails.

On environment and reliability: the master control and cellular module use the Qualcomm platform; power is supplied through a two-pin terminal block and a DC socket for redundancy; operating temperature is -20°C to +70°C; hardware and software dual watchdog support 24/7 operation; surge, EFT and ESD protection are included; wall mounting and DIN rail mounting are both available. On certification, multiple PUSR devices have obtained EU EN 18031 cybersecurity certification, so confirming that the target model is on the list is a reasonable step.

Remote management matters as well. Rules will be adjusted after rollout, and reaching the built-in web page through the remote management platform for parameter changes, reboots and firmware upgrades avoids a site visit for each one.

Allow All is the factory state; default deny is a result that has to be configured. The method itself is plain: the required permits written first, the catch-all deny last, and the inbound direction covered by a tunnel and tightly scoped port forwarding. A device that cannot be upgraded and cannot run protection software ends up with its network activity confined to that list. That is the most concrete securit