Firewall Settings for DLNA Discovery

[AlexEshoo]

Hi, I'm having an issue trying to get the DLNA integration to discover my sonos system and I've figured out it's due to my firewall, but I'm not sure what I should do to allow things to work.

I'm on cachy-os (arch) and running ufw firewall with default outgoing policy "Allow" and default incoming policy "Ignore".

If I disable ufw I can click the DLNA button in feishin and it discovers and plays to my sonos devices, but when the firewall is turned on, it cannot even discover the DLNA devices on the network.

Is this expected behavior? Are there specific ports I can allow through the firewall to make it work without disabling it? Also is this something the feishin package can ship with (a ufw config file with preconfigured ports)?

Thanks!

[jmrplens]

Yes, it is expected with a default-deny incoming policy, and the fix is to allow incoming traffic from the speakers' addresses. Discovery cannot be opened with a port rule, because both ends of the exchange use random ports.

Discovery sends an SSDP search to the multicast address 239.255.255.250:1900 from a socket bound to port 0, so the kernel picks a random port each time (src/main/features/core/dlna/ssdp-discovery.ts). Each speaker answers with a unicast packet from its own IP to that random port. Connection tracking cannot link that answer to the search, because the search went to the multicast address and the answer comes from a different one, so UFW sees a new incoming packet and drops it. The rule UFW ships in before.rules for 239.255.255.250:1900 does not help: it accepts multicast sent to port 1900, and Feishin never listens there. Sonos speakers also answer from a random port of their own (see the capture in this write-up), so a rule on source port 1900 does not work either.

So allow the speakers themselves:

sudo ufw allow from 192.168.1.50 comment 'Sonos living room'
sudo ufw allow from 192.168.1.51 comment 'Sonos kitchen'

Give the speakers fixed addresses (DHCP reservations) so the rules keep matching, or allow the whole LAN with sudo ufw allow from 192.168.1.0/24 if you are fine with that.

The same rules cover the other incoming connections Feishin uses. On Linux it starts an HTTP server with listen(0, '0.0.0.0'), again on a random port (src/main/features/core/dlna/index.ts), and subscribes to the speaker's events there. Those events are a shortcut, since Feishin also polls the speaker every 500 ms, but the same server is what hands the audio to the speaker when you change the playback speed: Feishin re-encodes the track with ffmpeg and serves it from there (/serve-temp). Normal playback, including transcoding done by your server, is fetched by the speaker straight from Navidrome. If Navidrome runs on this same machine, Feishin rewrites its localhost URLs to your LAN IP, and the speaker needs to reach Navidrome's port, which is fixed, so sudo ufw allow from 192.168.1.0/24 to any port 4533 proto tcp works for that one.

I reproduced it with the same socket code as ssdp-discovery.ts and a small SSDP responder standing in for a speaker, on a host running ufw 0.36.2 with deny (incoming):

UFW	Discovery	Speaker to Feishin's HTTP server
off	device found	200
on, default rules	nothing found	timeout
on, allow from <speaker IP>	device found	200

About shipping a UFW profile: a profile in /etc/ufw/applications.d can list ports or port ranges, but the only range that covers Feishin's random ports is the whole ephemeral range, which opens far more than allowing the speakers' IPs, and a profile opens nothing until you run ufw allow <name> anyway. It would need a setting for fixed ports first, which would make a reasonable feature request.

[AlexEshoo]

Thanks for the detailed response, I should be able to allow the speakers' IPs through and get it working.

EDIT: That was super easy, all working now 👍