UPnP incorrect a response port. (ROS v6.31)

RouterOS General
1

I has set strong firewall filtering rules and encountered a problem in UPnP - response packet from MikroTik does not match the destination port specified in the original request.
An example of a captured packet:

Request:
IPv4: Src: 192.168.88.2, Dst: 239.255.255.250
UDP: Src Port: 61042 (61042), Dst Port: 1900 (1900)
M-SEARCH * HTTP/1.1
Host: 239.255.255.250:1900
ST: upnp:rootdevice
Man: "ssdp:discover"
MX: 3

Answer:
IPv4: Src: 192.168.88.1, Dst: 192.168.88.2
UDP: Src Port: 49084 (49084), Dst Port: 61042 (61042)
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=3600
EXT: 
LOCATION: http://192.168.88.1:2828/gateway.xml
SERVER: RouterOS/6.31UPnP/1.0 MikroTik UPnP/1.0
ST: upnp:rootdevice
USN: uuid:UUID-MIKROTIK-INTERNET-GATEWAY-DEVICE-XXXX-XXXX::upnp:rootdevice

Because the connection tracking system for this response packet doesn’t assigned status ‘established’, and is regarded as ‘new’. I consider that this is a bug in the module UPnP in MikroTik, but until it is fixed necessary use of such a rule:

add chain=output protocol=udp content="MikroTik UPnP" comment="Allow UDP:UPnP-Respond"

Otherwise, if you use strict filtering and blocking the rest of the outbound traffic, UPnP will not work properly.

2

Today, the support[at]mikrotik.com has corrected part of the problem:

What’s new in 6.32rc6 Aug.27.15-11:22:34

*) trafflow - added support for IPv6 packets;
*) switch - fixed port flapping on switch ports of RB750, RB750UP, RB751U-2HnD and RB951-2N (introduced in 6.31)
*) ipsec - added compatibility option skip-peer-id-check;
*) flash - fix kernel failure (exposed by 6.31);
*) bridge firewall - add ipv6 src/dst addr, ip protocol, src/dst port matching to bridge firewall;
*) RB911/RB912 - fix SPI bus lock after fast led blink;
*) ipsec - fix potential memory leak;
*) bridge firewall - vlan matchers support service tag - 0x88a8;
*) ippool6 - try to acquire the same prefix if info matches recently freed;
*) crs switch - allow to unset port learn-limit, new default is unset to allow more than 1023 hosts per port;
*) x86 - fixed 32bit multi-cpu kernel support;
*) chr - add hotspot,btest,traffgen support;
*) revised change that caused reboot by watchdog problems introduced in v6.31;
*) ipsec - use local-address for phase 1 matching and initiation;
*) ipsec - fix transport mode ph2 ID ports when policy selects specific ip protocol on initiator;
*) certificates -fixed bug where crl stopped working after a while;
*) ip accounting - fixed kernel crash;
*) snmp - fix system scripts get;
*) hotspot - ignore PoD remote requests if no HotSpot configured;
*) hotspot - fix kernel failure when www plugin aborts on broken html source;
*) torch - add invert filter for src/dst/src6/dst6 addresses ;
*) bonding - add min_links property for 802.3ad mode;
*) snmp - get vlan speed from master interface;
*) hotspot - fix html-directory path on small flash devices;
*) mipsbe - make system shut-down work again;
*) lcd - fixed parallel port LCD display support on multi-cpu x86;
*) bridge - fixed use-ip-firewall-for-vlan in configurations with multiple bridges;
*) ipv6 - fixed DHCP-PD client skips some steps when renewing lease;
*) upnp - fixed protocol port selection for upnp protocol communications;
*) firewall - fixed limit and dst-limit options.

I checked and get next results:
Pre update:
16:57:39 F_UPnP-Request: LAN-ROS:
in:Bridge_home-LAN out:(none), src-mac 00:24:54:XX:XX:XX,
proto UDP, 192.168.24.101:63831->239.255.255.250:1900, len 165
16:57:39 F_UPnP-Respond: ROS-LAN:
in:(none) out:Bridge_home-LAN,
proto UDP, 192.168.24.254:49622->192.168.24.101:63831, len 351

After update:
17:19:34 F_UPnP-Request: LAN-ROS:
in:Bridge_home-LAN out:(none), src-mac 00:24:54:XX:XX:XX,
proto UDP, 192.168.24.101:58486->239.255.255.250:1900, len 129
17:19:34 F_UPnP-Respond: ROS-LAN:
in:(none) out:Bridge_home-LAN,
proto UDP, 192.168.24.254:1900->192.168.24.101:58486, len 282

However, the response packet still receives the status ‘new’, because the connection tracking system does not understand that in this protocol (UPnP/SSDP), request address - broadcast, and response - unicast.

This fix allows you to ease the rule for return packets (a smaller load of CPU), but it is still more necessary!

add chain=output protocol=udp src-port=1900 comment="Allow UDP:UPnP-Respond"

As far as I understand, are now required to make changes to the connection tracking system, for it correctly interpreted UPnP/SSDP protocol (UPD:1900) that the address of request is broadcast usually, such as it is implemented for DHCP.