MikroTik Port Forwarding (DNAT) Explained: Step-by-Step for RouterOS 7

Byadmin
Share
Tweet
Share
Pin
0 Shares

MikroTik port forwarding lets clients on the internet reach a specific service running on a device behind your router. In RouterOS 7, this is normally configured with destination NAT (DNAT): a rule in the dstnat chain rewrites the destination address and, optionally, the destination port of an incoming connection.

A working port forward needs more than a NAT rule. You also need a reachable public IP address, a stable private address for the server, a suitable firewall filter rule, and a service that is listening on the target device. This guide walks through the process in WinBox and the RouterOS CLI, then covers hairpin NAT, verification, and common problems.

Quick answer: the RouterOS 7 DNAT rule

Example: forward TCP port 8443 on the router’s WAN address to TCP port 443 on an internal server at 192.168.88.10. The example assumes your WAN interface belongs to the WAN interface list.

/ip firewall nat
add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=8443 action=dst-nat to-addresses=192.168.88.10 to-ports=443 comment="HTTPS port forward"

Then make sure the firewall’s forward chain permits the translated connection. If your existing firewall already accepts dst-natted traffic, you may not need another rule. Inspect the rules and their order before adding one. A narrowly scoped example is:

/ip firewall filter
add chain=forward in-interface-list=WAN connection-nat-state=dstnat     protocol=tcp dst-address=192.168.88.10 dst-port=443     action=accept comment="Allow forwarded HTTPS"

Place an allow rule before any rule that would otherwise drop the connection. Adjust the addresses, ports, and interface lists to match your network.

Table of contents

What is port forwarding (DNAT)?

Port forwarding maps traffic arriving at a router’s public address and destination port to a private address and port on your LAN. RouterOS implements the common IPv4 port-forwarding pattern with destination NAT, usually using chain=dstnat and action=dst-nat.

For example, a connection to 203.0.113.5:8443 can be translated to 192.168.88.10:443. The internal server receives the connection on its HTTPS port, even though the client connected to a different public port.

DNAT is different from source NAT (SNAT). DNAT changes the destination of incoming traffic; masquerade or other source-NAT rules commonly change the source address of outgoing traffic. RouterOS NAT rules are evaluated for the first packet of a connection, and connection tracking remembers the translation for subsequent packets. See the official MikroTik NAT documentation and connection tracking guide.

Before you start: prerequisites

  • A reachable public IPv4 address: your router must receive a public address, or your upstream modem/router must forward the required port to it. If your ISP uses carrier-grade NAT (CGNAT), ordinary inbound port forwarding on your MikroTik will not be reachable directly from the internet. Ask your ISP for a public address or use an appropriate VPN/reverse-access design.
  • A stable LAN address: reserve the server’s IP in DHCP or configure it statically. This example uses 192.168.88.10.
  • A working service: confirm the server is listening on the intended port and that its local operating-system firewall allows the connection.
  • Correct WAN identification: know which interface or interface list represents your internet connection. Many MikroTik configurations use the WAN interface list.
  • A safe exposure decision: publish only the service you actually need. Prefer a VPN for administrative access instead of exposing router management or remote desktop services to the whole internet.

If you are still setting up your router, see MikroTik’s First Time Configuration guide. You may also find our MikroTik NAT configuration guide useful for broader source-NAT and destination-NAT concepts.

How RouterOS processes a forwarded packet

For a typical inbound IPv4 connection, the packet enters the WAN interface and passes through the prerouting stage. The destination-NAT rule can translate the public destination to the private server address. RouterOS then makes its routing decision and processes the packet through the forward firewall chain because the destination is another host, not the router itself.

This is why a DNAT rule alone does not guarantee access. The NAT rule performs the address/port translation; the filter rules decide whether the routed packet is allowed. The RouterOS packet-flow documentation describes the processing path, while the firewall filter documentation explains the filter chains.

Configure MikroTik port forwarding in WinBox

  1. Connect to the router with WinBox and open IP → Firewall → NAT.
  2. Click + to add a rule.
  3. On the General tab, set Chain to dstnat.
  4. Set In. Interface List to WAN (or choose the actual WAN interface). Set Protocol to 6 (tcp) and Dst. Port to 8443.
  5. On the Action tab, choose dst-nat.
  6. Set To Addresses to 192.168.88.10 and To Ports to 443.
  7. Add a clear comment, such as HTTPS port forward, then click Apply and OK.
  8. Review IP → Firewall → Filter Rules. Confirm an appropriate forward-chain rule permits the dst-natted connection before any catch-all drop rule.

The MikroTik Knowledge Base also provides a port-forwarding walkthrough. Menu labels can vary slightly with WinBox and RouterOS versions.

Configure port forwarding with RouterOS 7 CLI

Forward a different external port to an internal port

This example accepts TCP 8443 from the WAN and forwards it to TCP 443 on the internal server:

/ip firewall nat
add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=8443     action=dst-nat to-addresses=192.168.88.10 to-ports=443     comment="HTTPS port forward"

Forward the same port internally and externally

To forward TCP 443 to TCP 443, omit to-ports:

/ip firewall nat
add chain=dstnat in-interface-list=WAN protocol=tcp dst-port=443     action=dst-nat to-addresses=192.168.88.10     comment="HTTPS to internal server"

Forward UDP traffic

For a UDP-based service, use protocol=udp and the service’s actual listening port:

/ip firewall nat
add chain=dstnat in-interface-list=WAN protocol=udp dst-port=51820     action=dst-nat to-addresses=192.168.88.20 to-ports=51820     comment="Example UDP service"

Do not create both TCP and UDP rules unless the application requires both. For a range of ports, use a matching range in dst-port and ensure the internal port mapping is appropriate for the service.

Restrict access to known source addresses

If only a known remote address should connect, add a source-address condition to the NAT rule (or enforce the restriction in the filter rule):

/ip firewall nat
add chain=dstnat in-interface-list=WAN src-address=198.51.100.25     protocol=tcp dst-port=8443 action=dst-nat     to-addresses=192.168.88.10 to-ports=443     comment="HTTPS forward from trusted source"

Replace the documentation-only address with the real trusted source address or subnet. Avoid this restriction if remote clients have unpredictable addresses and you have not designed an alternative access policy.

Allow the forwarded connection in the firewall

Inspect your existing filter rules before adding anything. Some standard RouterOS firewall configurations include a rule that accepts connections with connection-nat-state=dstnat in the forward chain. If that rule is enabled and correctly placed, it may already allow your new port forward.

If your policy requires a dedicated allow rule, scope it to the intended server, protocol, and translated destination port:

/ip firewall filter
add chain=forward in-interface-list=WAN connection-nat-state=dstnat     protocol=tcp dst-address=192.168.88.10 dst-port=443     action=accept comment="Allow forwarded HTTPS"

Place this rule above any general rule that drops new connections from WAN to LAN. Do not add a broad rule that accepts all traffic from WAN to the LAN. For a stricter policy, add source-address restrictions where practical. The RouterOS filter CLI reference documents the relevant matchers.

Hairpin NAT: access the public address from inside your LAN

Hairpin NAT (also called NAT loopback) is useful when LAN clients access an internal service using the router’s public hostname or IP address. Without a suitable loopback design, clients on the same LAN may fail to connect or may bypass the expected return path.

One common approach is a narrowly scoped source-NAT rule for LAN clients connecting to a dst-natted internal server:

/ip firewall nat
add chain=srcnat src-address=192.168.88.0/24     dst-address=192.168.88.10 connection-nat-state=dstnat     out-interface-list=LAN action=masquerade     comment="Hairpin NAT for internal server"

Adapt the LAN subnet, server address, and interface list. Review rule order and existing NAT rules to avoid unintended translations. For networks with reliable internal DNS, split-horizon DNS is often cleaner: resolve the service hostname to the server’s private address for LAN clients and to the public address for external clients.

Verify and troubleshoot your port-forwarding rule

Check that the NAT rule matches traffic

/ip firewall nat print stats
/ip firewall nat print detail

Generate a fresh connection from outside your LAN and check whether the rule’s packet and byte counters increase. Testing from a device on the same LAN may exercise hairpin NAT rather than the WAN path.

Inspect connection tracking

/ip firewall connection print where dstnat=yes

Connection tracking keeps the NAT decision for the lifetime of a connection. After changing a NAT rule, an already established connection may continue to use its existing translation. Test with a new connection; if necessary, remove only the specific stale connection entry after identifying it. Avoid flushing the entire connection table on a busy router.

For deeper diagnostics, see our guide to MikroTik connection tracking and NAT sessions.

Common symptoms and causes

  • The rule counters stay at zero: the connection may not reach this router, the wrong WAN interface/list may be selected, the public address may be elsewhere, or the client may be testing the wrong public IP/port.
  • The rule counter increases but the service is unreachable: inspect the forward filter chain, the server’s local firewall, the service’s listening address/port, and the server’s default gateway.
  • It works by private IP but not by public IP from the LAN: configure hairpin NAT or split DNS; this does not necessarily indicate that the external DNAT rule is broken.
  • It works briefly or only for some clients: check for stale connection-tracking entries, asymmetric routing, source restrictions, and upstream filtering.
  • No inbound connection arrives at all: verify the ISP has assigned a public IPv4 address. If the MikroTik WAN address is private or within CGNAT space, ask the ISP about a public IP or use a VPN/reverse tunnel.

Security recommendations for exposed services

  • Expose only the required service and port. Remove temporary rules when they are no longer needed.
  • Keep RouterOS and the server application updated, and back up the router configuration before significant firewall changes.
  • Do not expose WinBox, SSH, router web management, RDP, or other administrative interfaces to the entire internet. Prefer VPN access and restrict management services to trusted networks.
  • Where possible, restrict inbound connections by source address and use application-layer authentication, TLS, and multi-factor authentication.
  • Use comments on NAT and filter rules so the purpose and owner of each exception are clear.
  • Review logs and connection counters periodically, and remove unused forwards.

For a broader baseline, review our MikroTik firewall best practices and MikroTik hardening checklist. For backup procedures, see how to back up and restore a MikroTik configuration.

Does IPv6 use port forwarding?

IPv6 is different from the typical IPv4 DNAT pattern. In a normal IPv6 deployment, devices can have globally routable addresses, so inbound access is generally controlled with firewall filter rules rather than IPv4-style address translation. Do not copy an IPv4 port-forwarding rule and assume it applies to IPv6. Build an explicit IPv6 firewall policy and allow only the required traffic. See our MikroTik IPv6 configuration guide.

Frequently asked questions

What is the difference between dst-nat and masquerade?

dst-nat changes the destination of incoming traffic, commonly to forward a connection to an internal server. masquerade is a source-NAT action commonly used to translate outgoing LAN traffic to the router’s WAN address. They solve different problems.

Why is my MikroTik port-forward rule not working?

Check the public IP and upstream path first, then confirm the NAT rule matches the correct WAN interface, protocol, and external port. Next inspect the forward filter chain, the server’s local firewall, listening port, and default gateway. Test from a genuinely external network.

Do I need a firewall filter rule as well as a dst-nat rule?

DNAT performs the translation; the forward filter chain controls whether the routed packet is allowed. Your existing firewall may already allow dst-natted traffic. If not, add a narrowly scoped allow rule before the relevant drop rule.

Can I forward one external port to a different internal port?

Yes. Set dst-port to the external port and to-ports to the internal service port in the DNAT rule.

Why does port forwarding fail behind CGNAT?

With CGNAT, the router does not hold the public IPv4 address directly and unsolicited inbound traffic is usually blocked upstream. Ask your ISP for a public IPv4 address or use a VPN or reverse-access solution.

Why does a rule change not affect an existing connection?

RouterOS connection tracking remembers NAT state for established connections. Test with a new connection, or selectively remove the specific stale connection entry after identifying it. Do not clear all connection tracking entries without understanding the impact.

Conclusion

RouterOS 7 port forwarding is built around a destination-NAT rule in the dstnat chain, but a reliable setup also depends on a reachable public address, a stable server IP, a correctly ordered forward filter policy, and a service that is ready to accept connections. Start with one narrowly scoped rule, verify it from an external network, and keep the exposed service protected and updated.

For related administration tasks, see our guides to WinBox and CLI and MikroTik NAT on RouterOS 7.

Check our list of MikroTik guides

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *