Manual

A port forward that does not work

The dst-nat rule is in the script and still nothing arrives. Test from outside, then work down the list.

You opened a port for a web server, a camera or a game server. The rule is in the firewall, the device inside is running, and from outside nothing happens. Or it works on mobile data and not from the sofa.

That last sentence matters. If it works from outside and not from inside, this is not a port forward problem but hairpin, and that has its own paragraph below. If it works nowhere, work down the list.

Always test from outside. From your own Wi-Fi you are testing something other than what you think. Use your phone with Wi-Fi off, or a port checker on a website.

The quick checks, in this order

  1. Do you have a public address? /ip address print. A good answer: a public address on your WAN port. A private address, or anything in 100.64.0.0/10, means there is nothing to forward; see Behind two routers.
  2. Does the rule match anything? /ip firewall nat print stats, then knock from outside. A good answer: the counter on your dstnat rule climbs. Stuck on zero means the traffic never reaches the rule and the problem is in front of it.
  3. Is the interface list right? /interface list member print. The rule uses in-interface-list=WAN. If a VLAN interface or pppoe-out1 carries your public address while only the physical port is in the list, nothing matches.
  4. Is the connection allowed through? /ip firewall filter print stats. The closing rule is called drop all from WAN not DSTNATed and deliberately lets dstnatted connections pass. If that counter climbs while the nat counter climbs too, something is wrong with the order of your own extra rules.
  5. Does it reach the device? /tool torch interface=bridge port=443 while knocking from outside. A good answer: packets towards the internal address. If you see those and no reply comes back, it is the device itself.
  6. What does the connection table say? /ip firewall connection print where dst-port=443 shows whether the translation really happens.

The usual causes

  • There is another router in front. By far the most common. The provider's modem forwards nothing to your WAN address.
  • The device inside got a different address. The rule points at a fixed address and the device got another one after a reboot. Set a fixed lease on its MAC in the LAN and DHCP section.
  • The device's own firewall. Windows, a NAS and many cameras accept their own subnet only. The traffic arrives and is dropped inside.
  • Wrong internal port. Leave the internal port empty and it goes to the same port as outside. If the service listens on 8443, fill that in.
  • Only TCP opened while the service is UDP. Game servers and VoIP are often both. Pick TCP+UDP, which writes two rules.
  • The provider blocks the port. Port 25, and sometimes 80 and 443, are closed on consumer lines.

What the configurator does about it

The rule itself is generated the way it should be: one dstnat rule per forward, with in-interface-list=WAN, and the closing filter rule lets dstnatted connections through. You do not need an extra accept rule, which is exactly why that rule is called drop all from WAN not DSTNATed.

Hairpin NAT is on as soon as there is one forward in the list. That gives you a second dstnat rule for traffic from the LAN towards an address of the router itself, plus a masquerade rule so the reply comes back through the router. Turn hairpin off and your forward works from outside and not from inside.

Put a forward on 3389, 445, 23 or 21 and the tool warns you: that exposes a vulnerable service to the internet, prefer a VPN. See Checks about security.

What the tool does not have is a field to restrict the source addresses per forward. If you want that, use an address list with a custom filter rule, or, when the service runs on the router itself, the list of services on the router reachable from the internet: that one does have an only from field. The tool also does not check that the internal address exists in one of your networks.

When it is not your router

  • CGNAT. Without a public address of your own there is nothing to forward. A VPN set up from the inside is the answer.
  • The port checker is wrong. Some checking sites test TCP only. Test with a real client.
  • DNS points at the old address. With a name on a dynamic address, the name can still point at the previous IP for a while. See Dynamic DNS.

Further reading: Opening a port, Firewall and NAT and Remote access VPN.

Want to try it right away? Open the configurator