What is the purpose of SSDP packets that OS sends to the LAN?

[verfluchten]

Seeing non-stop SSDP packets from the router LAN iface to the LAN. What is the purpose of them? Which function of OS depends on them being sent?

[meyergru]

For starters, I do not see this.

I would argue that this is not OpnSense that produces this, unless you have something specific running, like a broadcast relay of some sort. SSDP is a discovery protocol that works via broadcasts. There are some devices that use it for UPnP. What comes into mind are DLNA clients or certain HomeAssistant integrations.

There have been DDOS-Attacks (ab)using SSDP as well.

[verfluchten]

Are you suggesting that OS routes then from the WAN?

[meyergru]

Not neccessarily. All I am saying, is that the SSDP packets do not normally originate from OpnSense. I can guess only three possibilities in descending order of probability:

1. Some devices on your network(s) that use SSDP for whatever reasons. Potentially, you use a broadcast repeater like os-broadcast-relay or os-mdns-repeater that mirrors these requests to other (V)LANs.

2. Some plugin or daemon installed on OpnSense like os-upnp or others. Since there are many that I do neither use nor know, it may be something you installed on top of a plain vanilla OpnSense which does this, maybe Zenarmor?

3. Something outside your own network that emits SSDP requests, which may be repeated on your (V)LANs, although I think that such attempts should be discarded by the firewall, if correctly configured.

You did not write how you detected this or gave packet dumps to see which types of packets (src ip/port, dest ip/port, protocol) are actually transmitted and on what interfaces.

[verfluchten]

UPnP plugin is installed and active, but isn't it supposed to work as a server rather than actively send out?

NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=60
LOCATION: http://x.x.x.x:2189/rootDesc.xml
SERVER: FreeBSD/12.1-RELEASE-p20-HBSD UPnP/1.1 MiniUPnPd/2.1.20200510
NT: upnp:rootdevice
USN: uuid:528c8e6c-4a3c-6598-999a-0e9df15ad32::upnp:rootdevice
NTS: ssdp:alive
OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
01-NLS: 1747339380
BOOTID.UPNP.ORG: 1747339380
CONFIGID.UPNP.ORG: 1337

I tried to create a firewall rule to block source LAN iface port 1900/udp. Also tried destination 239.255.255.250. But packets keep coming.
I just don't want this noise on my LAN, which serves no purpose. When my few select applications ask for UPnP, they will tell the plugin that they do. Until then no one is interested in anything it might want to say.

[EricPerl]

Cute warning during the install of that plugin...

I believe that this is literally UPnP advertising its services (many different USNs).
You can actually grab the xml at that LOCATION.

[meyergru]

So it was #2 from my list: you installed os-upnp, which implements UPnP, so there is your answer.

You cannot block those SSDP packets on LAN "in", because they originate from OpnSense. The UPnP protocol implies this, because it advertises its services like that and MiniUPnPd does, too.

[verfluchten]

Sounds like a gap in OS firewall

[meyergru]

Hardly. You can filter that via a LAN "out" rule, although I am at a loss on why you would want that. I pointed out why your rule did not work.

[verfluchten]

You can argue that, but like I wrote, packets keep coming despite the rule that is supposed to block them. If you want to be helpful, you could word your replies in positive terms such as this and this should be done, but you are only writing in negatives such as something does not work, which makes you hard to understand.

[Patrick M. Hausen]

Try:

Interface: LAN
Direction: out
Source: any
Destination: 239.255.255.250
Protocol: UDP
Source and Destination port: any
Action: block

Then again these announcements are a mandatory part of a UPnP service. It simply tells devices on the LAN that it is there. As it should according to the standards.

HTH,
Patrick

[meyergru]

Try a rule like the one depicted in my screenshot. But note this:

1. The packets will still be generated and probably be seen in logs - they will not leave your firewall, though.
2. If this works, then maybe (or most probably) your UPnP will not work any more. If so, you will come here again and complain about something that works as designed and even put into an RFC, only not what you think it should work like.

P.S.: Patrick told you essentially the same. Did I make my point clear enough, now?