Hello,

I want to forward all unmapped ports to a specific LAN IP (this function is called "DMZ" in home routers), for that I've added a NAT rule: and it works.

However, dynamic UPnP port forward rules are added after my "DMZ" rule, and thus do not work, unless I manually move my rule below those dynamic UPnP rules.

Please share your knowledge on how to realize this "DMZ" function properly, with UPnP working.

Thank you in advance, and hope it helps many MikroTik newcomers.

You may be out of luck. I'm not aware of any option where dynamic rules should be added.

Normally, if you have only some selected ports forwarded, adding dynamic ones at the end makes sense, because you don't want them to override static ones. E.g. if you have public webserver on port 80, you don't want random device from LAN to steal this port for itself. But in your case the logic is reversed.

The solution would be, if UPnP added ports to dedicated chain and you could put jump to it anywhere you want to have it. But currently it doesn't do that.

It's unfortunate such a feature packed RouterOS is unable to do what a cheapest TP-Link can.

I really hope MikroTik will simplify port forwarding in the future to a home router convenience level (a WinBox wizard or something), and implement this widespread "DMZ" feature.

For me, port forwarding is currently the weakest spot of otherwise excellent RouterOS.

That's two things.

1) Port forwarding is already simple. I understand that some will disagree, but if adding (and understanding) some simple rules is too difficult for them, maybe those people don't really want a complex system like RouterOS. I don't mean to be too harsh, and I wouldn't discourage anyone from buying MikroTik devices, but people should be prepared to learn at least some basics (and I'm helping beginners with that all the time). It's just that RouterOS offers great flexibility, but that requires certain level of knowledge.

But good news, RouterOS does have simple mode called Quick Set, for those without any special requirements, and latest version (6.48) added simplified port forwarding to it. It had some flaws when I tested it, but I'm sure they'll polish it and it will be ok.

2) As for "DMZ" feature, it's possible, with the rule you already found. Problem is with your specific use case, which I think is kind of weird. You want everything forwarded to selected device, but only as long at it's not taken by some other device. So I'm not really sure what is it good for, because it's completely unpredictable, any port can by claimed by any other device at any time.

But even though it seems weird to me, I fully agree that such config should be supported. Because that's the beauty of RouterOS, it allows to do even crazy things that don't make sense (either just to anyone else, or at all). Unfortunatelly, this one is currently not possible.

When I want specific port X to be forwarded... I don't think I'd want it to be randomly overridden by <any> device, just because it happens to have access to my LAN.
This is, in a way, compatible with UPnP as the same port could be forwarded to only one device at a time, so the only change needed is taking into account that forwarding is taking place.

Does Mikrotik's UPnP support that by the way? I.e. if I am forwarding a single port, could it still let UPnP client to try to forward it? (I realize it would likely fail as UPnP service seems to kick in after all FW processing is done, but would UPnP client be notified about it, or would it assume that it is listening, but just receive no data?)
DMZ + UPnP is a bit unusual "forward everything to that host, unless there are dynamic clients for that port".


I imagine both cases would be addressed if we could explicitly call out UPnP service in firewall rules.

Sob

1) IMO understanding netfilter is much more complex and specific than general networking knowledge. If a person is not familiar with netfilter, port forwarding on RouterOS is actually harder than most other RouterOS stuff.

Upgraded to v6.48 today, and found the Port Mapping button (it shows up when "NAT" is checked). It's pretty much what I imagined MikroTik should do, a great step forward.
But I will not be using it, because I have my forwards configured as in https://wiki.mikrotik.com/wiki/Hairpin_NAT (but with address-lists instead of hardcoded addresses) and my forwards don't show up in the wizard. It would be nice if configuration created by this wizard would work exactly as Hairpin_NAT, e.g. if I map port 80 to a web server in LAN, accessing router's WAN_IP:80 would NAT me to the web server, but accessing router's LAN_IP:80 would open router's web interface.
Another bad - the wizard doesn't allow to specify several ports at once (which I heavily use), and not specify target (internal) port (leave unchanged).

Also a "target" (to-address : to-port) column on WinBox NAT page would be VERY nice, I could see everything I need in a single table (like in a TP-Link), and not have to double-click each rule to check target, and then keep it in my head, or manage comments.

2) TP-Link DMZ page says it's useful to pass all external ports to an internal sub-router. I most often use DMZ for testing port forwarding before doing it properly, as a time-saving feature.

My current use case for DMZ is actually weird.
I use it to play Mario Kart Wii on Wiimmfi servers. Up to 12 people gather in a P2P room where everyone is sending data to everyone else. Although it is designed to work through NAT, I get disconnects very often if I NOT use DMZ.
Actually, I have two Wiis for playing Mario Kart with a friend both at 60fps, and the only solution to play together without disconnects every few races was to install a second fiber to get a separate global IP address (my ISP can't do 2 IPs on one fiber), and use my primary internet with DMZ for one Wii, and a separate internet for the second Wii (Wii itself gets the global IP).
If I accidentally leave my DMZ rule disabled, the Wii using it will surely get disconnected first, or even unable to join some rooms altogether.
I understand the disconnects are most probably due to Wiimmfi or other players' NAT misbehavior, but it's really nice to be able to fix it on my side using DMZ, and not deep-dive to sniff how exactly Wii communicates with the several servers and other players.

medi01

I've tested MikroTik's UPnP using UPnP Wizard - it actually does allow to map a port already statically mapped to a different target, but only the rule which is higher in the NAT table works. UPnP rules are added to the bottom, so UPnP-mapped server silently gets no data if this port was already statically mapped.

Also I tried to UPnP-map a TCP port which is already used.
If the port is used by a NATted TCP session from a LAN host, everything works perfectly, mapping is created and connection from WAN is received, the old NATted TCP session doesn't break either.
If the port is used by MikroTik itself (e.g. source port of a Telnet session), UPnP mapping fails.

My quick test says that the whole thing is currently pretty dumb, UPnP is aware of only own ports. So if I use UPnP to forward port, next request to forward same port elsewhere will fail. If the port is manually forwarded, UPnP is happy to add duplicate and tell client that it's ok (but it's a lie, because it won't be reachable).

So there's room for improvement, but it doesn't look like easy task, because of how flexible dstnat rules are. UPnP would have hard time to recognize what rule is actually conflicting. Looking at protocol and port number wouldn't be enough, because there could be other conditions that make it non-conflicting.

But maybe it's not really a problem in practice. Most people probably use just one, either manually added rules, or UPnP exclusively. If there's going to be combination of the two, it's likely that it will be manually forwarded ports for webserver or something, and UPnP for everything else. Chances for conflict should be low.

Solution for your request could be new option for UPnP, what chain to use. Let's say you'd tell it to use chain "upnp". Then you could have priorities any way you'd like:
But it doesn't help with conflicts between UPnP and manually added rules.

If a person is not familiar with netfilter, port forwarding on RouterOS is actually harder than most other RouterOS stuff.

Well, I admit that it may not be immediatelly obvious to someone used to simple home routers. But it's not that much more difficult. If they are used to providing external and internal port and internal address, here it's just additional external address (or in-interface=<WAN> as popular shortcut). And most people are happy with that (e.g. hairpin NAT is bonus that not everyone needs).

Also a "target" (to-address : to-port) column on WinBox NAT page would be VERY nice, I could see everything I need in a single table ...

Right-click on list and look for "Show Columns" in menu.

Right-click on list and look for "Show Columns" in menu.

Thank you, somehow I missed that! (it's ⏷ button in WinBox)

I guess the best solution at the moment is to schedule a task to execute this every few seconds:

Also I tried to UPnP-map a TCP port which is already used.
If the port is used by a NATted TCP session from a LAN host, everything works perfectly, mapping is created and connection from WAN is received, the old NATted TCP session doesn't break either.
If the port is used by MikroTik itself (e.g. source port of a Telnet session), UPnP mapping fails.

That's interesting. So the latest device to request port gets it.
Not necessarily the best way to handle things in my opinion (especially from security POV).

I think it was port used by outgoing connection, not another port opened by UPnP. And it's ok, connection tracking can deal with that. It would only be problem, if remote host from the first connection tried to connect to this newly forwarded port, and if it would use same source port as the original connection has as destination.

i used /ip firewall nat add action=dst-nat chain=dstnat in-interface-list=WAN to-addresses=192.168.1.99
and it creates a perfect dmz

but now i am locked out of winbox that uses port 8291 how can i exempt port 8291 from above rule?

i used /ip firewall nat add action=dst-nat chain=dstnat in-interface-list=WAN to-addresses=192.168.1.99
and it creates a perfect dmz

but now i am locked out of winbox that uses port 8291 how can i exempt port 8291 from above rule?

That should only be a problem if you are attempting to access WinBox from a WAN interface - which you SHOULD NOT BE DOING!