MikroTik NAT + Firewall:
the reasoning behind the script
The generator builds the config in seconds. This page covers why each rule exists — for any MikroTik gateway, not just PPPoE or Hotspot deployments.
Why masquerade should be scoped to your LAN, not "all traffic"
The simplest NAT rule on RouterOS is a masquerade with no source condition at all — translate everything going out the WAN interface, no exceptions. It works, but it's imprecise: if the router ever gets a second internal network added later (a management VLAN, a second office segment), that traffic gets silently masqueraded too, with no record of where it actually came from.
Scoping the rule to your actual LAN subnet — src-address=192.168.1.0/24 — means only traffic that's supposed to be there gets translated. It costs nothing in performance and saves a confusing debugging session six months later when a new subnet appears and traffic from it doesn't behave the way the untouched masquerade rule assumed.
Which ports actually get scanned, and why it matters
MikroTik routers with a public IP on the WAN interface get scanned constantly — not because anyone specifically targets a given router, but because RouterOS's management ports sit on the same well-known numbers on every deployment. Bots sweep public IP ranges looking for exactly these:
| Port | Service | Why it's a target |
|---|---|---|
8291 | Winbox | Full GUI router management — the highest-value target if compromised. |
23 | Telnet | Unencrypted management — credentials visible to anyone on the path. |
21 | FTP | File access to the router's own filesystem. |
8728 / 8729 | API / API-SSL | Programmatic access — used by billing platforms, but only from your own IP, not the WAN. |
None of these need to be reachable from the public internet. You manage the router from the LAN, or through a VPN tunnel (WireGuard is the simplest option on modern RouterOS) if you need remote access. Closing them on the WAN interface specifically — not globally — keeps LAN-side management untouched.
SSH is a judgment call: unlike the ports above, SSH has legitimate remote-management use cases and is harder to brute-force meaningfully with a strong key-based login. The generator's hardening option treats it as optional rather than closing it by default.
Port forwarding: the door you're choosing to open
A dst-nat rule that forwards one external port to an internal device — a camera, a small web server — is sometimes necessary, but it's worth being deliberate about it. Every forwarded port is reachable from the entire public internet, not just from you. The generator's port-forwarding block is opt-in and scoped to exactly one port pair for this reason: it should be something you consciously add, not a default.
If you only need occasional access rather than an always-open port, a WireGuard tunnel or a reverse SSH connection is usually a better trade-off than a permanent forward.
How brute-force protection actually works
Closing management ports on the WAN stops most scanning cold, but it's still worth adding a second layer: an address-list rule that tracks repeated connection attempts to router services and temporarily blacklists the source. In RouterOS terms, this is usually two rules working together — one that adds an offending address to a list after repeated attempts, and one earlier in the chain that drops anything already on that list.
This catches what static port-closing alone doesn't: an address hammering a port left open for a legitimate reason (like SSH), or probing before a rule further down the chain would otherwise catch it.
How a packet is actually evaluated
Reading the generated script
In order, here's what each block in the generator's output does:
| Block | Purpose |
|---|---|
/ip firewall nat | Masquerade rule scoped to your LAN subnet, plus an optional dst-nat port-forward if enabled. |
/ip firewall filter (input) | Accept established/related, drop invalid, then drop the specific WAN-side management ports selected. |
| Brute-force block | Address-list rules that blacklist repeated connection attempts before they reach the login prompt. |
/ip firewall filter (forward) | Same established/related and invalid-drop baseline used in the PPPoE and Hotspot generators — applies regardless of which side traffic originates from. |
Test before you trust it: if you manage this router remotely, keep a Winbox or console session open while applying firewall changes for the first time — a misordered rule can lock you out of your own router. Test on a device you can reach physically before relying on this in production.
This generator vs the PPPoE and Hotspot generators
If you're already using the PPPoE generator or Hotspot generator, note that both already include their own baseline firewall rules (established/related accept, invalid drop, optional Winbox/Telnet block). This NAT + Firewall generator is most useful for a standalone gateway that isn't running PPPoE or Hotspot at all, or when you want the extra layers this page covers — scoped masquerade, port forwarding, and brute-force protection — on top of what those two already set up.
Every parameter, explained
| Field | Accepts | Default | Notes |
|---|---|---|---|
| WAN interface | Interface name (e.g. ether1) | ether1 | The masquerade and hardening rules apply to this interface specifically. Required. |
| LAN subnet | IPv4 CIDR block | 192.168.1.0/24 | Scopes the masquerade rule — only traffic from this subnet gets translated. |
| Port forwarding toggle | Checkbox | off | Enable only if a specific internal service needs to be reachable from the internet. |
| External / Internal port | Number, 1–65535 | 8080 | The public-facing port and the port the internal device actually listens on — can differ. |
| Internal IP | IPv4 address | 192.168.1.100 | Should fall inside the LAN subnet above. |
| Block Winbox/Telnet/FTP/API | Checkbox | on | The single highest-impact hardening option — closes the most commonly scanned ports on the WAN. |
| Block SSH | Checkbox | on | Optional judgment call — SSH has legitimate remote-access uses, unlike the ports above. |
| Brute-force protection | Checkbox | on | Adds address-list rules that blacklist repeated connection attempts. |
Full example: hardening a standalone gateway router
A common scenario: a MikroTik router acting as a plain internet gateway for an office LAN, with one internal NVR that needs remote camera access.
| Field | Value used |
|---|---|
| WAN interface | ether1 |
| LAN subnet | 192.168.1.0/24 |
| Port forwarding | Enabled — TCP, external port 8080 → internal 192.168.1.100:8080 (the NVR) |
| Service hardening | Winbox/Telnet/FTP/API blocked, SSH blocked |
| Brute-force protection | Enabled |
Everything on the router is managed from the LAN or through a WireGuard tunnel — the one forwarded port is deliberately the NVR's port and nothing else.
Common mistakes and how to fix them
| Symptom | Likely cause | Fix |
|---|---|---|
| Devices on the LAN lose internet after applying the script | Masquerade rule scoped to the wrong subnet — doesn't match actual LAN addressing | Confirm the LAN subnet field matches the router's real internal network exactly |
| Locked out of Winbox after running the script | Managing the router through the WAN interface the script just hardened | Reconnect from the LAN, or via a VPN tunnel set up before hardening — see the security guide |
| Forwarded service unreachable from outside | Internal IP or port typo, or the internal device's own firewall blocking the connection | Double-check the internal IP is correct and the device itself accepts connections on that port |
| Brute-force rule doesn't seem to block anything | Address-list timeout too short, or the rule order has the accept rule before the blacklist check | Confirm the blacklist-drop rule appears before any accept rule for the same port in /ip firewall filter print |
Best practices
- Only forward ports you actually need — every forwarded port is reachable from the entire public internet.
- Prefer a VPN tunnel over a permanent port forward for occasional remote access.
- Test firewall changes on a device you can reach physically, or keep a console session open the first time.
- Review the LAN subnet field whenever the network topology changes — a stale scope silently stops protecting new segments.
Ready to generate your config?
Fill in your WAN interface and LAN subnet and get a ready-to-import .rsc file in seconds.