Build firewall policy
Create ordered tenant rules, service-scoped restrictions, and captive walled-garden entries safely.
The Firewall page manages tenant policy enforced by Linux nftables on each enabled edge. It contains three different views: editable tenant rules, read-only system rules, and captive-access exceptions.
Know the three rule sets
| NOC tab | Purpose | Operator ownership |
|---|---|---|
| Firewall Rules | Ordered filter or NAT policy for tenant traffic | Create, edit, enable, reorder, and delete |
| System Rules | DHCP, captive listener, authorization, NAT, and safety anchors generated by URUFI | Read-only |
| Walled Garden | Pre-login destinations, bypass devices, and explicitly blocked devices | Create and delete |
System rules are visible so operators can understand the complete effective policy, but they cannot be reordered around the enforcement anchors.
1. Define the outcome first
Write the intended result before opening the form. For example:
Block ICMP from Guest service clients to 1.1.1.1.
Allow other authorized traffic to continue through the managed policy.Avoid broad rules until a narrow rule has been tested. Firewall policy is ordered and first-match-wins inside the operator section.
2. Create the rule
Open Firewall → Firewall Rules → Add rule.
| Field | Guidance |
|---|---|
| Chain | Use forward for client traffic through the gateway; input targets the gateway itself; NAT chains are for deliberate translation |
| Action | accept allows, drop silently discards, reject returns an error; dnat requires a destination target |
| Service | Scope to one service class or all clients; only forward/input accept, drop, or reject rules support service scope |
| Protocol | Choose tcp, udp, icmp, or any |
| Source/Destination | One IP or CIDR; use the narrowest correct scope |
| Ports | One port or a range, meaningful for TCP/UDP |
| Interfaces | Optional advanced constraint; prefer logical address/service scope unless the interface is stable |
| Comment | State the business reason and intended traffic |
Save the rule, then place it in the intended order with the up/down controls.
3. Use service scope for product policy
A service-scoped rule applies only to devices whose current authorization carries that service class. This keeps package policy independent of DHCP pool and VLAN. For example:
Guest Basiccan block a destination whileStaffcan reach it;- both users may remain on the same subnet;
- changing the account's effective service class updates firewall membership without a DHCP renew.
Author and order the rule on Firewall. The matching service-class drawer displays it read-only so policy has one editing authority.
4. Configure captive exceptions
Use Walled Garden only for pre-login access:
- walled garden permits a destination needed before authorization;
- bypass permits a specific MAC without portal login;
- blocked denies a specific MAC.
Permit only the portal and essential dependencies. Avoid adding broad public ranges, because every unauthenticated client can reach a walled-garden destination.
5. Test from a real client
After the policy reaches the agent, test both the blocked and allowed control case:
ping -c 4 -W 2 1.1.1.1
ping -c 4 -W 2 8.8.8.8For a rule blocking only 1.1.1.1, the first command should lose all packets and the
second should succeed. Repeat tests from a client in another service class to prove the
scope is correct.
Do not test only from the gateway
Tenant forward rules match client traffic crossing the edge. A command run on the
gateway itself follows a different chain and does not prove the client policy.
Recovery rule
If a new rule is wrong, disable it first and verify recovery before deleting it. If the agent is temporarily disconnected, its last-known-good firewall and authorization state continue locally and the current full snapshot repairs state after reconnect.
Next step
Create reusable bandwidth profiles for the rate portion of the tenant's service tiers.