Can't get UPnP to work in RouterOS 7.14.1 (Worked in RouterOS 6.x)

RouterOS General
1

Hi,

I’m used to configuring routers with UPnP, and the same configuration that works for me in RouterOS 6 doesn’t work in RouterOS 7.
This is what I get when I try to check UPnP:

yomach@yoav-laptop:~$ upnpc -l
upnpc : miniupnpc library test client, version 2.1.
 (c) 2005-2019 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
No IGD UPnP Device found on the network !

This is my RouterOS 7 configuration:

# 2024-08-12 15:24:48 by RouterOS 7.14.1
# software id = FUKC-6DF7
#
# model = RB3011UiAS
# serial number = HGF09WBQJW9
/interface bridge
add admin-mac=D4:01:C3:A9:B9:52 auto-mac=no comment=defconf name=bridge
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/ip pool
add name=dhcp ranges=192.168.88.101-192.168.88.254
/ip dhcp-server
add address-pool=dhcp interface=bridge name=defconf
/port
set 0 name=serial0
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether9
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=sfp1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set disable-ipv6=yes
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=\
    192.168.88.0
/ip dhcp-client
add comment=defconf interface=ether1 use-peer-dns=no
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ip service
set www port=81
/ip upnp
set enabled=yes
/ip upnp interfaces
add interface=ether1 type=external
add interface=bridge type=internal
/lcd
set default-screen=interfaces
/system clock
set time-zone-name=Asia/Jerusalem
/system note
set show-at-login=no
/system routerboard settings
set enter-setup-on=delete-key
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

This is my RouterOS 6 configuration (This works):

# aug/12/2024 14:35:00 by RouterOS 6.47.10
# software id = PL1S-31UH
#
# model = RB3011UiAS
# serial number = E7E70F849E7F
/interface bridge
add admin-mac=DC:2C:6E:AA:78:19 auto-mac=no comment=defconf name=bridge
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.88.101-192.168.88.254
/ip dhcp-server
add address-pool=dhcp disabled=no interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=ether9
add bridge=bridge comment=defconf interface=ether10
add bridge=bridge comment=defconf interface=sfp1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=\
    192.168.88.0
/ip dhcp-client
add comment=defconf disabled=no interface=ether1 use-peer-dns=no
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,8.8.8.8
/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input dst-port=81 in-interface=ether1 protocol=tcp
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
/ip service
set www port=81
set www-ssl certificate=WebFig disabled=no
/ip upnp
set enabled=yes
/ip upnp interfaces
add interface=ether1 type=external
add interface=bridge type=internal
/lcd
set default-screen=interfaces time-interval=hour
/system clock
set time-zone-name=Asia/Jerusalem
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
2

Can you post the ouput of:

/ip/upnp print
/ip/upnp/interfaces print
3

There is at least another case where upnpc had troubles with detecting the UPNP:
http://forum.mikrotik.com/t/cant-get-upnp-to-work/171172/1
but actual devices were actually working.

You seem to be running an older version:

(c) 2005-2019 Thomas Bernard.

than the OP in the other thread:

(c) 2005-2022 Thomas Bernard.

It is possible that there is some incompatibility between upnpc and current Mikrotik’s implementation.

A difference I noticed between your configurations is a firewall filter “fasttrack” rule with “hw-offload=yes” but on the other thread it was reported as being unrelated.

4

Yes:

[admin@MikroTik] > /ip upnp print
                           enabled: yes
  allow-disable-external-interface: no
                   show-dummy-rule: yes
[admin@MikroTik] > /ip upnp interfaces print
Columns: INTERFACE, TYPE
# INTERFACE  TYPE
0 ether1     external
1 bridge     internal



Yes, I saw that thread, but I wasn't able to find any useful hints on how to solve it.
I tried with "hw-offload=no", it didn't change it (also rebooted the router to double check)
I also ran it on a different computer which has a newer miniupnc, and I got the same thing:

upnpc : miniupnpc library test client, version 2.2.1.
 (c) 2005-2020 Thomas Bernard.
5

That one seemingly solved by itself, upnpc couldn’t find the device but upnp did work on the OP network.

Sort of what is reported here:
https://superuser.com/questions/873998/miniupnp-thinks-my-router-doesnt-support-upnp

But your case is much more specific (and “better” for troubleshooting/sending a support ticket) as you have it working on 6.xx, but failing on 7.xx.

I cannot spot any other meaningful difference between your two configurations.

There is still the possibility that something has changed in the way Mikrotik “advertises” the service, and upnpc cannot detect this new way, but really cannot say.

6

Thanks. I’ve actually made a few discoveries.

I’ve ran it on the latest version of miniupnp, 2.2.7, and got an interesting message:

(base) ➜ ~ upnpc -l
upnpc: miniupnpc library test client, version 2.2.7.
 (c) 2005-2024 Thomas Bernard.
More information at https://miniupnp.tuxfamily.org/ or http://miniupnp.free.fr/
List of UPNP devices found on the network :
 desc: http://192.168.88.1:2828/gateway_description.xml
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1
Found a (not connected?) IGD : http://192.168.88.1:2828/upnp/control/evzadwbdnz/wanipconn-2
No valid UPNP Internet Gateway Device found.

Now, in the previous version, the desc was under “http://192.168.88.1:2828/gateway.xml”, and it seems that this is where miniupnpc looks for it (I guess?)
So running I tried running “upnpc -u http://192.168.88.1:2828/gateway_description.xml -l” gives:

upnpc -u http://192.168.88.1:2828/gateway_description.xml -l
upnpc : miniupnpc library test client, version 2.1.
 (c) 2005-2019 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
Found valid IGD : http://192.168.88.1:2828/upnp/control/evzadwbdnz/wanipconn-2
Local LAN ip address : 172.18.185.120
Connection Type : IP_Routed
Status : Connected, uptime=3995s, LastConnectionError : ERROR_NONE
  Time started : Mon Aug 12 17:41:01 2024
MaxBitRateDown : 10000000 bps (10.0 Mbps)   MaxBitRateUp 10000000 bps (10.0 Mbps)
ExternalIPAddress = 192.168.116.138
 i protocol exPort->inAddr:inPort description remoteHost leaseTime
 0 TCP     0->0.0.0.0:0     'Dummy inactive rule for windows to work' '' 0
GetGenericPortMappingEntry() returned 713 (SpecifiedArrayIndexInvalid)

And this is what we get in RouterOS 6:

root@192.168.88.11 qm-d063b4034fc7 ~
# upnpc -u http://192.168.88.1:2828/gateway.xml -l
upnpc : miniupnpc library test client, version 2.2.1.
 (c) 2005-2020 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
Found valid IGD : http://192.168.88.1:2828/upnp/control/ierllhemis/wanipconn-1
Local LAN ip address : 192.168.88.11
Connection Type : IP_Routed
Status : Connected, uptime=322049s, LastConnectionError : ERROR_NONE
  Time started : Thu Aug  8 18:11:04 2024
MaxBitRateDown : 10000000 bps (10.0 Mbps)   MaxBitRateUp 10000000 bps (10.0 Mbps)
ExternalIPAddress = 172.16.33.101
 i protocol exPort->inAddr:inPort description remoteHost leaseTime
 0 TCP     0->0.0.0.0:0     'Dummy inactive rule for windows to work' '' 0
 1 TCP    80->192.168.88.11:80    'libminiupnpc' '' 0
 2 TCP  1883->192.168.88.11:1883  'libminiupnpc' '' 0
 3 TCP  9510->192.168.88.11:9510  'libminiupnpc' '' 0
GetGenericPortMappingEntry() returned 713 (SpecifiedArrayIndexInvalid)

You can see that the IGD changed from “wanipconn-1” to “wanipconn-2”
I have zero knowledge on what it means, but it seems that RouterOS 7 broke a few things…

7

Well, you are mixing the upnpc versions, try using ONLY the latest 2.27.

This way results would be comparable.
Run:

upnpc -l

on both the 7 and 6 devices.

Then

upnpc -u http://192.168.88.1:2828/gateway_description.xml -l

on the 7
and

upnpc -u http://192.168.88.1:2828/gateway.xml -l

on the 6.

The issue could be “both sides”, Mikrotik changed something and upnpc is not (yet) ready for these changes.

The fact that somehow it gets (on the 7) the dummy rule:

 0 TCP     0->0.0.0.0:0     'Dummy inactive rule for windows to work' '' 0

should mean that the upnp is actually running on the Mikrotik.

8

Unfortunately, I cannot, or at least not easily.

We’re using MikroTiks as OEMs in a production env, and our devices have miniupnpc version 2.2.4 (of course we can update, but it is used in production, so it’s a process)
My debug computer has version 2.1, and I cannot update to a newer one as it has Ubuntu 20.04 (and this is the latest which is supported there).
It is connected to a new batch of routers we got with RouterOS 7, so I also don’t have a handy RouterOS 6 device…

I used a dev computer with 2.2.7, but I don’t have access to it right now (Can maybe get it tomorrow).


I agree that the issue could be both sides, but it’s still a breaking change, so it’s annoying.
My best solution, at least so far, is to downgrade the routers back to RouterOS 6

9

Yep, I would actually reverse the prospective: why did you upgrade (now) to 7.14.1?
If you have some setup working nicely why do you want to risk an issue with it (unless version 7.xx offers some new feature that you actually need)?

Still, when you have time/the opportunity it would be nice if you could complete the tests and post results and (if I were you) I would submit a support ticket with them.

The issue with newish batches will be that they are already (factory firmware) 7.4 or 7.8 so you won’t be able to downgrade them to 6.x

10

I didn’t, I got a new batch with this version, and we noticed that it broke our production line. And, as you said, I just found out that I cannot downgrade them.

Tried upgrading to the latest stable just to check, and it’s the same issue.

I think I have enough to submit a ticket, where do I do it though?

11

Here:
https://mikrotik.com/support

12

Thx.
We’re buying through a distributor, we’ll start with them.

13

Small update

The “successful” version I had, with 2.2.7, was with a Mac.
I’ve installed a new computer with an updated Ubuntu, and installed the latest stable version 2.2.8 on it.
It also fails:

yomach@yoav-laptop:$ upnpc -l
upnpc: miniupnpc library test client, version 2.2.8.
 (c) 2005-2024 Thomas Bernard.
More information at https://miniupnp.tuxfamily.org/ or http://miniupnp.free.fr/

No IGD UPnP Device found on the network !

yomach@yoav-laptop:$ upnpc -i -r 80 80 tcp 1883 1883 tcp
upnpc: miniupnpc library test client, version 2.2.8.
 (c) 2005-2024 Thomas Bernard.
More information at https://miniupnp.tuxfamily.org/ or http://miniupnp.free.fr/

No IGD UPnP Device found on the network !
14

Adding for closure.
Mikrotik responded through their jira support system, and acknowledged it’s a bug introduced in 7.13.
It will be fixed in 7.17.

Here is their response:

Elvijs Īvāns11 minutes ago

Hello,

Thank you for contacting MikroTik Support. 

 Sorry for the inconvenience caused. This was introduced with the introduction with DLNA, we have now fixed the issue, but it will be available only the next beta builds.  These changes were made from v7.13 upwards. 
If you are able to downgrade to 7.12 you can use this version until 7.17beta or stable is released with the changes in it. https://help.mikrotik.com/docs/display/RKB/Downgrading+RouterOS

Best regards,
15

Good :slight_smile: , so you can temporarily go for 7.12.
But did the new batch come with already 7.14.1? If yes it must be new-new, 7.14.1 came out at the end of march 2024 .
Unless you cannot manage to use 7.12 - since it is in production - I would wait for a non-beta version with the feature fixed before upgrading

16

Yes, we have routers that came with 7.14.1 from the factory :astonished:

We have enough older routers in stock to wait until 7.17 is out, but we also implemented a fix: manually trying with the “wrong” file path. It’s simple, and it works.

So we’re covered all around. Besides wasting some time, we’re good.

17

@jaclaz you may be interested on this:

What’s new in 7.17beta2 (2024-Sep-27 10:07):

*) upnp - rename service description file from gateway_description.xml back to gateway.xml;

18

Good news :slight_smile: , thanks.