NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: IP → Firewall → Filter Rules → +, set *Chain* forward, *Protocol* tcp, *Dst. Port* 443, *In. Interface* ether1, then the Action tab → accept. Drag the rule above your drop rule.
2. CLI: /ip firewall filter add chain=forward action=accept protocol=tcp dst-port=443 dst-address=192.168.88.10 in-interface=ether1 comment="allow web" place-before=0
3. For traffic to the router itself use chain=input instead of forward.
4. Verify placement with /ip firewall filter print.

Gotchas & notes

• Rule order is everything and RouterOS appends new rules to the bottom — below your drop catch-all, where they will never match. Always use place-before= on the CLI or drag the rule up in WinBox.
• There is no implicit deny in RouterOS. A stock router with the default config has a drop rule at the end of input/forward; on a wiped config everything is permitted and your accept rule is redundant.
• Pick the right chain: input = traffic to the router, forward = traffic through it, output = from the router. Opening a port on a LAN server needs forward, not input.
• Filter rules see the post-NAT destination, because dstnat runs first. With a port forward in place, match on the internal IP (192.168.88.10), not the public one.
• Add a comment= to every rule. Six months later print output with no comments is unreadable, and MikroTik has no rule-name field.

Steps

1. Create the address object first: Policy & Objects → Addresses → Create New (e.g. web-server = 192.168.1.10/32).
2. Create the service if it is non-standard: Policy & Objects → Services → Create New.
3. Policy & Objects → Firewall Policy → Create New: set *Incoming Interface*, *Outgoing Interface*, *Source*, *Destination*, *Schedule* always, *Service*, *Action* ACCEPT, and the NAT toggle as appropriate.
4. CLI: config firewall policy → edit 0 → set name "allow-web" → set srcintf "port1" → set dstintf "port2" → set srcaddr "all" → set dstaddr "web-server" → set action accept → set schedule "always" → set service "HTTPS" → next → end

Gotchas & notes

• You cannot type an IP directly into a policy — FortiOS requires a named address object. Coming from pfSense or MikroTik this feels like three steps too many, and it is the most common early stumble.
• There is an implicit deny at the bottom of every interface pair. Anything you do not explicitly allow is dropped, which is the opposite of a wiped MikroTik.
• Policies are evaluated in sequence order within the interface pair. In the GUI use *By Sequence* view and drag; the ID number is not the evaluation order.
• edit 0 in the CLI means 'create with the next free ID'. Using an existing ID silently edits that policy instead of creating one.
• Traffic destined to the FortiGate itself (management, VPN termination) is not matched by firewall policies — it is controlled by set allowaccess on the interface and by local-in policies. Writing a policy to allow HTTPS to the firewall's own IP has no effect.
• For inbound traffic to an internal server you almost always need a VIP as the destination, not a plain address object — see the port forwarding task.

Steps

1. UniFi Network 9.x (Zone-Based Firewall): Settings → Security → Policy Table / Firewall Rules → Create Policy, pick source zone and destination zone, define source/destination and port, Action Allow.
2. UniFi Network 7.x–8.x: Settings → Firewall & Security → Firewall Rules, choose the right ruleset tab (*Internet In*, *LAN In*, *LAN Local*), Create New Rule.
3. Define reusable objects under Settings → Profiles (or *Firewall Groups* in older versions) for port and address groups.
4. Order matters — set the rule index / drag it above conflicting rules.

Changed across versions

• 8.x and earlierDirectional rulesets under Settings → Firewall & Security → Firewall Rules, split across *Internet In*, *LAN In*, and *LAN Local* tabs.
• 9.0+Zone-Based Firewall replaces the directional model outright — traffic is matched by source/destination zone rather than by ruleset tab. Requires a UniFi Gateway on firmware 4.1+. The migration from the old rulesets is one-way: reverting means restoring a pre-migration backup, not toggling a setting.
• 9.3 – 9.4The zone policy editor itself keeps moving — seen at Settings → Security → Zone-Based Firewall and later folded into Settings → Policy Table → Create New Policy. If a menu below doesn't match your screen, look for "Policy" in Settings.

Gotchas & notes

• The menu path for firewall rules has changed in nearly every major UniFi Network release, and 9.x replaced the old directional rulesets with zones outright. Check your version before following any guide, including this one.
• Getting the ruleset right is the whole trick in pre-9.x: *Internet In* = WAN→LAN, *LAN In* = traffic entering the gateway from a LAN (the one you want for inter-VLAN rules), *LAN Local* = traffic to the gateway itself. Inter-VLAN blocking goes in LAN In, which surprises people who expect 'LAN Out'.
• Firewall rules only exist on UniFi gateways (UDM/UDM-Pro/UXG/USG). A UniFi-switch-and-AP-only site has no firewall to configure here.
• Auto-generated rules from other features (port forwards, VPN, guest networks) sit above yours with predefined indices; your manual rule can be shadowed by one you did not write.
• Changes trigger a gateway provision, which can briefly interrupt traffic — not something to do casually mid-day on a UDM.

Steps

1. Build a named extended ACL: ip access-list extended WAN_IN → permit tcp any host 192.168.1.10 eq 443 → permit icmp any any echo-reply → deny ip any any log
2. Apply it in a direction on an interface: interface GigabitEthernet0/0 → ip access-group WAN_IN in
3. Insert into an existing ACL without rebuilding: ip access-list extended WAN_IN → 15 permit tcp any host 192.168.1.20 eq 22
4. Verify: show access-lists WAN_IN and show ip interface Gi0/0 | include access list

Gotchas & notes

• A plain ACL is stateless. Permitting inbound 443 does not permit the return traffic for outbound sessions — you need permit tcp any any established, or a stateful feature (Zone-Based Firewall / CBAC), or you will break all outbound traffic the moment you apply the ACL.
• Every ACL ends in an implicit deny ip any any. Applying a one-line ACL to an interface blocks everything else instantly — including your own SSH session. Have console access.
• Use sequence numbers to insert lines. Without them, ip access-list extended NAME appends to the end, below your deny — the same trap as MikroTik.
• Apply direction is relative to the interface: in means entering the router on that interface. Applying an inbound-intent ACL with out is a classic mistake.
• Reordering or re-editing a numbered ACL in one go can drop traffic mid-edit. On production, build a new named ACL and swap the ip access-group in one command.

Steps

1. Create the address object: Objects → Addresses → Add.
2. Policies → Security → Add: *Source Zone*, *Source Address*, *Destination Zone*, *Destination Address*, *Application*, *Service* (application-default is the recommended default), *Action* Allow.
3. Move the rule to the correct position with the Move button — order is top-down, first match wins.
4. Commit (top right). Nothing is live until the commit completes.
5. CLI: configure → set rulebase security rules allow-web from untrust to dmz source any destination web-server application ssl service application-default action allow → commit

Gotchas & notes

• Forgetting to Commit is the number one PAN-OS mistake. The rule exists in the candidate config, the GUI shows it, and it does nothing. The commit also takes 30–120 seconds, so plan for it.
• Rules match on zones, not interfaces. Two interfaces in the same zone talk freely by default (implicit intrazone-allow), so adding a rule to block them requires overriding that default rule.
• The destination in a rule for inbound NATted traffic must be the pre-NAT IP while the zone must be the post-NAT zone. This asymmetry is the single most confusing thing about PAN-OS and breaks most first attempts at a port forward.
• application-default restricts the allow to the app's standard ports; combined with App-ID it means a rule can permit port 443 and still block a non-TLS tunnel on it. That is the intended behaviour, not a bug.
• Default rules at the bottom are intrazone-allow and interzone-deny, and neither logs unless you override them. Enable logging on interzone-deny early — it saves hours.
• Before committing, use Device → Troubleshooting → Security Policy Match to confirm the new rule wins over the ones above it.

Steps

1. Firewall → Rules, select the tab for the interface the traffic arrives on (e.g. *WAN*), then Add.
2. Set *Action* Pass, *Interface*, *Protocol* TCP, *Destination* (the internal IP or WAN address), *Destination port range* HTTPS, and a *Description*.
3. Save, then Apply Changes on the banner.
4. Optional: define reusable aliases first under Firewall → Aliases.
5. CLI: not supported for rule editing — the GUI writes config.xml; hand-editing is unsupported.

Gotchas & notes

• pfSense filters inbound on each interface only. There is no outbound-direction ruleset by default, so a rule to control LAN→WAN traffic goes on the LAN tab, not WAN. Putting it on the wrong tab is the most frequent pfSense error.
• pfSense is stateful, so return traffic is automatic — no 'established' rule needed, unlike a Cisco ACL.
• Each interface tab ends in an invisible default deny, and WAN has no pass rules out of the box. LAN ships with an 'allow LAN to any' rule that people forget is there when they think they have locked things down.
• If you created the port forward first, pfSense probably already added the matching WAN rule for you (the *Filter rule association* field). Adding a second rule by hand is redundant.
• Floating rules (the *Floating* tab) can match any interface and any direction and are evaluated first with quick semantics — check there when a rule inexplicably has no effect.
• Changing a rule does not kill existing states. Clear the relevant entries in Diagnostics → States to make a new deny take effect immediately.

Steps

1. If the destination is a specific host, create an Address Object first: Object → Address Objects → Add (e.g. Web-Server-LAN, zone = LAN).
2. Create a Service Object if the port isn't a built-in one: Object → Service Objects → Add.
3. Policy → Rules and Policies → Access Rules — this page is a matrix of zone-pair tabs (From Zone/To Zone), e.g. WAN→LAN. Open the correct tab and click Add.
4. Set *Source* (Any or restricted), *Destination* (the address object or the relevant interface IP), *Service*, *Action* = Allow, and optionally enable logging.
5. Save. Confirm the rule sits above any broader deny/allow rule in the same zone-pair that would otherwise match first.

Changed across versions

• SonicOS 6.5 (Gen6)Same concept but the page is simply Firewall → Access Rules, not nested under a 'Rules and Policies' group.

Gotchas & notes

• SonicOS is zone-based like FortiGate/PAN-OS, not a flat ordered list like MikroTik/Cisco: traffic between zones is implicitly denied unless a rule (or one of the pre-shipped defaults) allows it. Out of the box it ships with WAN→LAN/DMZ deny-all and LAN→WAN allow-all already in place — you're usually adding to, not replacing, that baseline.
• The GUI organizes rules into per-zone-pair tabs rather than one flat list. Admins used to a single ordered rule table (MikroTik, Cisco ACLs) sometimes create the rule in the wrong From/To Zone tab and then can't find it later.
• Within a zone-pair tab, rules are evaluated top-down; a broad Any/Any rule sitting above a specific one will silently absorb the traffic first. There's no automatic hit-count highlighting in the rule list itself — check the Log to confirm which rule actually matched.
• If the destination is a public IP that's NAT'd to an internal host, the destination here needs special handling — see the port-forward task; getting this wrong (matching the internal host instead of the original address) is the most common reason an inbound rule 'does nothing'.
• The CLI cannot create or edit Access Rules at all in SonicOS — this is one of the areas explicitly reserved for the GUI, so don't go looking for an SSH equivalent.

Steps

1. There is no standalone 'firewall allow rule' object on Insight-managed routers/Orbi Pro — the SPI firewall blocks all unsolicited inbound WAN traffic by default, and the only user-facing way to open a hole in it is to create a Port Forwarding entry, which allows and translates in the same step.
2. Insight app or portal → Locations → select the router/Orbi Pro device → Security (or Firewall) → Port Forwarding → Add Service, then fill in protocol, external port, and internal IP/port. Saving this entry is simultaneously the 'allow' action.
3. If what you actually want is inbound access to the router/AP's own management plane (its cloud-adopted HTTPS/SSH, or a site-to-site VPN endpoint) rather than to a LAN host, that is controlled separately under Security → Remote Management / VPN, not by a firewall rule at all — there is no local-in policy concept to edit.
4. For Smart Switches and M4200/M4300, this task does not apply: those are Layer 2/L3 switches in the Insight lineup and do not run a stateful WAN firewall — the closest analog is a port/VLAN ACL, which is a different feature entirely.

Gotchas & notes

• Coming from FortiGate/pfSense/MikroTik where 'allow' and 'NAT' are separate objects, this is disorienting: on Insight routers you cannot permit inbound traffic to a LAN host without also translating it, because the two concepts were never split apart in the product.
• There is no rule list, no ordering, no implicit-deny-you-can-inspect — the firewall behavior is fixed SPI logic baked into firmware. You get a handful of exposed knobs (port forwarding, port triggering, DMZ, VPN passthrough), not a policy engine.
• Because routers and Orbi Pro have zero CLI, there is no show/get equivalent to confirm a rule is actually active beyond looking at the same GUI list you created it in — no CLI cross-check is possible on this platform, unlike every other vendor in this comparison.
• If you're expecting a 'default deny, add allow rules' mental model, you'll be looking for a screen that simply doesn't exist here — plan around port forwarding as the only lever.