Hello!

I don't think that it is a big deal to make some UPnP client for RouterOS. This feature would be useful (as we got build-in DDNS and until world will totally moved on IPv6) to open a routerboard to the world then it is not a gateway (and the gateway is not yours) but you have to manage it sometimes. The primal solution is VPN-client but it's little awkward to maintain connections for month of testing/support periods. There is utilities for PC and even cheap DVR's can behave themselves as a manageable UPnP clients but ROS devices don't.

I agree with this feature request - Espesically with how often ISP are now providing Modem/Router combo devices, it would be nice to be able to use a upnp client on ROS to punch a hole in a router that is infront of the mikrotik (ie to punch a hole for TCP 8291 for winbox for example).

tks

I think UPnP is generally a no-no - it's a cancer of any network, it simplifies spreading of malware and introduces magic into network equipment (which is the last place you want it!).

i am interested also in this idea as many providers now providing their own modem-routers and i install a mikrotik device for hotspot as a second device.
it would be a nice idea to upnp port 8291 so i can access mikrotik device for remote support.

It's not a solution - you should bridge ISP device and get from there.

sometimes you dont want to touch the device or the network that is setup to provider modem-router. (voip, provider internet tv etc)

Not needed. Too risky that someone could enable it without understanding the consequences. Just set up a port forward manually if you can't bridge.

You can ban whole RouterOS outright with "too risky" argument.

Watch this video, and then come back if you still want to have UPnP

https://www.youtube.com/watch?v=3JqsEcgQQt8

Of course, this is "unsecured" UPnP - but alas, there's not really much of it built into the protocol anyway because hey, that would defeat the entire purpose of PnP if you had to configure it first. . .

Devil's advocate here, and let me start by saying that my client is almost completely innocent, it's just an unfortunate misundertanding!

Sure, UPnP IGD might have not been designed with much emphasis on security. But if some manufacturer implements it in a way that it accepts requests from WAN, you can't seriously want to blame UPnP for that, it's royal screw up on manufacturer's part. It must be obvious to everyone, just from missing authentication (which, granted, might be seen by some as unfortunate design decision, but what can you do if it's supposed to "just work") that UPnP was meant for LAN.

Another complaint was about ability to forward ports to external addresses (RouterOS allows that, btw). Again, blaming UPnP is not exactly fair. It might look bad at first, but take a closer look and you'll find out that it's actually useful feature. You might be tempted to limit port forwards only to requesting machine, but it's not hard to imagine legitimate scenarios where one machine controls port forwarding for others. And regarding internal vs. external addresses, it's not that simple. You can't just limit it to local /24 (typically), because you can have larger internal network with multiple subnets. And even if they are not all able to talk to UPnP server directly, there's again the "controller" scenario. You can't simply throw this all out as wrong.

But my client is prepared to admit, that external addresses might be bad in typical "clueless home user" scenario, and a recommendation should be made for manufacturers, to evaluate a possibility to perhaps add some additional limits by default.

In conclusion, UPnP did nothing wrong, it's a victim too. It just comes from older, simpler times, when there was more trust and less evil hackers. It just aimed to make the world a nicer place, where things would work better and with less effort. It couldn't predict that there would be so many bad people who's malicious actions would ruin this beatiful vision. Even if you don't like UPnP IGD, you still have to admit that you do need something similar, you do need something to control incoming connections. Do you remember current recommedation for IPv6, to block incoming connections by default? You need some way to deal with that. There is one (PCP), more modern, with autentication, etc. So by all means, take that one and view UPnP IGD as outdated if you wish. But please don't be harsh on poor UPnP!



And btw, the request was for client, it couldn't do much harm, if any. Not counting development time, which given that it's not exactly a high priority feature, can be spent better on something else, that's for sure.

Short answer: no.

I need UPnP client too or some type of UPnP relay to work in routed environments.

Not all networks or use cases are the same!
And tbh I can't see what would be the big deal about UPnP client. AFAIK server is the main security concern, not client.
If RouterOS gets compromised, UPnP client would be the least of our worries, that's for sure.

The 'too risky' argument is just false IMHO.

-It's also risky to have the ability to disable interfaces. You can get locked out of the whole router if you disable the wrong interface. Should we remove the disable buttons then?
-It's also risky to allow users to define their own firewall rules. You can lock yourself out, or even worse allow traffic through that shouldn't be allowed. Should we change the awesome firewall UI with some D-Link type firewall with on/off button?
-It's also risky (for everyone else!) to allow the DNS resolver to be an open resolver to the internet and be part of DNS Amplification attacks. Should we ditch DNS or should RouterOS become a pfsense/openwrt clone with that stupid WAN/LAN interface designation forcing you into "boxes"?
-It's also risky to have BGP UI with nice buttons because this allows for users to easily advertise bad prefixes to the whole internet (as has happened IRL). Should we go back to the dark ages and configure everything with CLI (not that it's not extremely useful - I am just trying to prove a point) because using GUIs can lead to mistakes?


So risky for who?
If I operate heavy machinery that would be risky since I know nothing about them. If a trained professional does there's no risk about it. It's his/her job.
I don't see any difference in IT and Networks.
There's nothing risky about having new features available in our 'networking toolbox' that is called MikroTik RouterOS.

Users (even trained professionals) will always make mistakes even if whole RouterOS was just a single on/off button.
If stupid users were MikroTik's target group we wouldn't be here talking about it. RouterOS would be a TP-Link, Netgear, D-Link clone, and we wouldn't give a dime about it

I need UPnP client too or some type of UPnP relay to work in routed environments.

Cha0s, are you sure you're not confusing UPnP w/something like mDNS or Bonjour? UPnP is to punch holes through NAT dynamically. People here are asking for a method to tell RouterOS to act as a UPnP client and be able to punch holes in upstream NAT. These customers I presume are behind CGN already.

Now, to address the larger theme. The big wigs of the Internet community would rather leave NAT traversal techniques and protocols to die. Issues like this are seen as drivers to adopt IPv6 instead of trying to work around ever increasing layers of NAT. Now, along those lines do we really want any client internally to be able to alter our firewall configuration? Any compromised client could in theory open you up entirely. This is even less appealing if applications continue to traverse NAT in a more common fashion (the established, related route on initiated sessions).

I agree with this feature request - Espesically with how often ISP are now providing Modem/Router combo devices, it would be nice to be able to use a upnp client on ROS to punch a hole in a router that is infront of the mikrotik (ie to punch a hole for TCP 8291 for winbox for example).

Looking at one specific reason in the thread. Being able to allow WinBox access to a device behind at least 1 layer of upstream NAT. A working alternative is to build a NAT traversing VPN (client on the device behind NAT and server somewhere with a public IP). This is very similar to what Meraki does, each device creates 2 tunnels. A tunnel to each of their DCs (a 3rd is programmed into the device but not used until 1 of the 2 primary VPNs fail). You can then also VPN into the head-end or the LAN behind the head-end if you set it up at say your office and manage the device as needed. Also, not being able to bridge a providers device is the entire reason I don't use ATT U-Verse and I wouldn't use any other provider managed device personally.

I know what UPnP is and I know why I need what I asked.

I don't care about what the "big wigs" think or want about NAT or any other technology/tool.

Nobody will tell me how to run my network.

This is a great feature, when providing server why not client?

+1

I support this feature request. ROS already has the dangerous UPNP server. Why not add UPNP client for cases where ROS device is not the WAN router.
This would be useful e.g. for requesting the routers WAN address by UPNP to make use of it in ROS (e.g. ping it).