MikroTik NAT & Port Forward Generator

Generate RouterOS dst-nat port forwards and src-nat/masquerade rules, complete with the hairpin NAT rule that everyone forgets until internal users complain.

Config generator MikroTik / RouterOS Runs in your browser
Single port, list (80,443) or range (5000-5010).
Try:

Result

Port forward (dst-nat)
/ip firewall nat
add chain=dstnat action=dst-nat in-interface=ether1 protocol=tcp dst-port=443 to-addresses=192.168.88.10 to-ports=443 comment="Netvorx: forward 443 to 192.168.88.10:443"
Matching filter rule
/ip firewall filter
add chain=forward action=accept connection-nat-state=dstnat protocol=tcp dst-address=192.168.88.10 dst-port=443 comment="Netvorx: permit forwarded traffic"
Hairpin NAT (internal clients using the public name)
/ip firewall nat
add chain=srcnat action=masquerade protocol=tcp src-address=192.168.88.0/24 dst-address=192.168.88.10 dst-port=443 comment="Netvorx: hairpin NAT"

Summary

External
ether1 tcp/443
Internal
192.168.88.10:443
Source restriction
none - open to the internet
Address scope of target
Private
Unrestricted forward
This forward is open to the entire internet. Anything you expose will be scanned within minutes - restrict the source range, or put the service behind a VPN, unless it genuinely must be public.

About MikroTik NAT & Port Forward Generator

RouterOS NAT is straightforward until a detail is missing - the filter rule that permits the forwarded traffic, or the hairpin rule that lets internal users reach the service by its public name. This generates all three parts together.

Why the hairpin rule exists

An internal client resolving your public hostname sends traffic to the WAN address. dst-nat rewrites the destination, the server replies directly to the client's private address, and the client drops the reply because it came from an address it never contacted. Masquerading that specific internal-to-internal flow forces the return path back through the router and fixes it. Split-horizon DNS solves it more elegantly, but the NAT rule works everywhere.

Rule order

NAT rules are evaluated in order within each chain, first match wins. Put specific dst-nat rules above any broad ones, and remember that in-interface is what stops a forward applying to LAN-sourced traffic.

Common use cases

  • Exposing a web, mail or VPN service on a business connection.
  • Setting up remote access to a NAS or camera recorder from a restricted source range.
  • Fixing "the site works from outside but not from the office" complaints with hairpin NAT.

Edge cases and gotchas

  • A port forward bypasses your firewall for that destination - the filter rule and the service's own hardening are what protect it.
  • CGNAT subscribers cannot receive port forwards at all; no router configuration can change that.
  • Never forward Winbox (8291), SSH or RDP to the internet without a source restriction.

Frequently asked questions

The forward works from outside but not inside - why?
You need hairpin NAT, or split-horizon DNS that resolves the public name to the internal address for LAN clients. The rule above implements the former.
Do I need the filter rule if my firewall has a default accept?
Not strictly, but a default-accept forward chain is the real problem. Add the specific accept and then close the chain.