NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: IP → Firewall → NAT → + → *Chain* srcnat, *Out. Interface* ether1 → Action tab → masquerade.
2. CLI: /ip firewall nat add chain=srcnat action=masquerade out-interface=ether1 comment="default masq"
3. Better on multi-WAN: use an interface list — /ip firewall nat add chain=srcnat action=masquerade out-interface-list=WAN
4. For a fixed public IP prefer action=src-nat to-addresses=203.0.113.10.

Gotchas & notes

• The default RouterOS config includes one masquerade rule scoped to the WAN interface, so a new VLAN usually gets internet automatically — as long as the rule matches by out-interface and not by src-address.
• If the existing rule is written as src-address=192.168.88.0/24, your new subnet gets no NAT and appears to have 'routing but no internet'. Check the existing rule before adding a second one.
• action=masquerade recalculates the source address per packet and is the right choice for dynamic WANs; src-nat is more efficient and preferable when the public IP is static.
• A masquerade rule without out-interface will NAT internal-to-internal traffic too, breaking inter-VLAN visibility and hiding source IPs from your own servers.

Steps

1. Outbound NAT is a per-policy toggle: edit the LAN→WAN firewall policy and enable NAT, with *Use Outgoing Interface Address* selected.
2. For a specific address, choose *Use Dynamic IP Pool* and pick an IP pool created under Policy & Objects → IP Pools.
3. CLI: config firewall policy → edit <id> → set nat enable → end
4. With a pool: set ippool enable → set poolname "my-pool"

Gotchas & notes

• FortiGate has no global outbound NAT table — NAT is a property of each firewall policy. A new VLAN with a new policy and the NAT toggle left off gets routed but not translated, so it silently has no internet.
• This is the mirror image of the port-forwarding confusion: the same *NAT* checkbox that you must enable for outbound is the one you must leave off for inbound VIP policies.
• Central NAT mode (config system settings → set central-nat enable) switches the box to a pfSense-style separate NAT table and removes the per-policy toggle entirely. It is disruptive to enable on a live unit and changes how every policy behaves.
• IP pools must be within a subnet the upstream router will route back, and arp-reply needs to be enabled on the pool for the FortiGate to answer for those addresses.

Steps

1. Nothing to configure: creating a network under Settings → Networks gives it outbound NAT and internet access automatically.
2. To restrict it, add firewall rules (see the inbound-port task) or set the network's *Purpose* / isolation options.
3. Advanced source NAT is not exposed in the UI.

Gotchas & notes

• UniFi hides outbound NAT completely — it just works for every LAN you create. Convenient, but it means there is no knob when you need a non-default source address.
• Because internet access is automatic, a new VLAN is reachable outward the moment it exists. Isolation is opt-in, not opt-out, so remember to add the block rules for guest/IoT networks.
• The *Guest* network type applies built-in isolation, which is easier than hand-writing rules for that case.

Steps

1. Define what to translate: ip access-list standard NAT_SRC → permit 192.168.1.0 0.0.0.255
2. Overload onto the WAN interface: ip nat inside source list NAT_SRC interface GigabitEthernet0/0 overload
3. Mark the interfaces: interface Gi0/1 → ip nat inside; interface Gi0/0 → ip nat outside
4. Verify: show ip nat translations / show ip nat statistics

Gotchas & notes

• The overload keyword is what makes it PAT (many-to-one). Without it, IOS tries a 1:1 mapping and runs out of addresses immediately — traffic works for the first host and stops.
• Adding a new subnet means editing the NAT ACL. Forgetting that step is the standard 'new VLAN has no internet' cause on IOS.
• Note the wildcard mask in the ACL (0.0.0.255), not a subnet mask — a persistent source of typos.
• Both ip nat inside and ip nat outside must be present somewhere or the whole feature is inert.
• On IOS-XE, prefer ip nat inside source list ... pool ... overload with a NAT pool if you have multiple public addresses.

Steps

1. Policies → NAT → Add. *Original Packet*: source zone trust, destination zone untrust, destination interface = WAN, source address = your subnet.
2. *Translated Packet* → Source Address Translation → Dynamic IP And Port → *Interface Address* → select the WAN interface.
3. Commit.
4. Verify: test nat-policy-match source <ip> destination 8.8.8.8 protocol 6 destination-port 443 and show session all filter ...

Gotchas & notes

• Dynamic IP And Port is PAN-OS's name for PAT/masquerade. Dynamic IP (without 'And Port') is a 1:1 pool that exhausts, and Static IP is a fixed mapping — picking the wrong one is a common mis-step.
• NAT rules are matched top-down and only the first match applies, so a broad early rule shadows the specific one you just added below it.
• A new zone or subnet needs both a security policy *and* a NAT rule. Traffic that is allowed but untranslated leaves with a private source and never comes back — it looks like an ISP problem.
• Setting *Interface Address* rather than a literal IP keeps the rule correct across a WAN IP change.

Steps

1. Firewall → NAT → Outbound. Default mode is *Automatic outbound NAT rule generation*, which already NATs every internal subnet.
2. To customise, switch to Hybrid Outbound NAT and add your rules — hybrid keeps the automatic rules and applies yours first.
3. Add a rule: *Interface* WAN, *Source* your subnet, *Translation address* WAN address (or a specific VIP).
4. Save → Apply Changes.

Gotchas & notes

• Automatic mode means a new VLAN gets outbound NAT with no action from you — pfSense and UniFi behave alike here, unlike FortiGate and Cisco.
• Choose Hybrid rather than Manual when you need one custom rule. Switching to Manual copies the current automatic rules once and then stops updating them, so a VLAN added later has no NAT and no warning.
• To make traffic leave from a specific public IP, create an IP Alias VIP first, then reference it as the translation address.
• *Static Port* matters for protocols that break under port rewriting (some VoIP/IPsec cases) — set it per-rule rather than globally.

Steps

1. Check the existing defaults first: Policy → Rules and Policies → NAT Policies. SonicOS ships with a broad default policy (*Original Source* = Any, *Original Destination* = Any, *Translated Source* = WAN Primary IP) that is not scoped to a specific subnet.
2. If the new VLAN/interface is assigned to an existing Trusted zone (e.g. LAN) and routes out the same WAN, it typically inherits that default policy automatically — no new NAT Policy is needed.
3. If you need to scope translation explicitly (multiple WANs, a new custom zone, policy-based routing), add one: NAT Policies → Add, *Original Source* = address object for the new subnet, *Original Destination* = Any, *Translated Source* = the WAN interface IP, *Outbound Interface* = the correct WAN port.
4. Verify the Access Rule permitting the new zone out to WAN exists: Policy → Rules and Policies → Access Rules, new-zone→WAN tab. If you created a brand-new custom zone, its creation dialog has a checkbox to auto-generate default Access Rules to/from other zones — confirm it was checked, or add the Allow rule manually.

Gotchas & notes

• Unlike FortiGate (where a new interface typically needs an explicit outbound policy written by hand), SonicOS's default NAT Policy is written broadly ('Any' source) rather than per-subnet, so a newly added VLAN usually gets outbound NAT for free as long as it lands in an existing Trusted zone — the translation half of this task is often already done before you touch anything.
• What's NOT automatic is the Access Rule. A new custom zone's traffic is still subject to the implicit interzone deny; if the 'auto-generate Access Rules' checkbox was skipped at zone creation, or the zone's security type was left as Untrusted/Public, packets get translated correctly but are still dropped — which looks exactly like a NAT problem and sends people troubleshooting the wrong layer.
• With multiple WAN interfaces or WAN failover/load-balancing configured, the default NAT policy may be bound to one specific outbound interface — a secondary WAN can silently lack the equivalent automatic translation until you clone the policy for it.
• No CLI path exists for NAT policy configuration on this platform.

Steps

1. Nothing to configure for the common case: any LAN or VLAN you create on an Insight-managed router or Orbi Pro under Insight app/portal → Locations → device → LAN/VLAN Settings → Add Network is automatically NAT'd (masqueraded) out the active WAN interface the moment it's created.
2. There is no separate 'enable NAT for this subnet' toggle, no source-NAT policy object, and no way to view a masquerade rule anywhere in the GUI — it's implicit, always-on router behavior.
3. If you have multiple WANs configured (failover or, on some BR models, dual-WAN), the outbound NAT simply follows whichever WAN is currently active — you don't pick a translation address per subnet.
4. No CLI equivalent exists to inspect or override this, since routers/Orbi Pro carry no CLI at all.

Gotchas & notes

• This is the opposite failure mode from pfSense/MikroTik: on those platforms a new VLAN can silently have no internet access until you add an outbound NAT rule for it. On Insight-managed routers a new VLAN gets internet access automatically — there is no equivalent 'forgot the NAT rule' outage, but there is also no way to build a VLAN that is routed-but-not-NAT'd (e.g. for a site-to-site setup expecting real source addresses to cross the WAN) — Insight routers don't expose that option.
• If you need policy-based or selectively-disabled outbound NAT (common on FortiGate/pfSense for site-to-site VPN traffic that must stay un-NAT'd), you will not find a knob for it here — traffic routed to a configured VPN tunnel is typically excluded from NAT automatically by the VPN feature itself, but this is not something you configure or verify directly.
• Smart Switches and M4200/M4300 are L2/L3 devices without a WAN-facing NAT function, so 'outbound NAT' is not a concept that applies to them in the Insight lineup.