Configuring firewall for discovery

[aleasto]

In Ubuntu 24.10, with UFW enabled and the /etc/ufw/applications.d/wsdd profile allowed, the discovery feature is not working.

Wireshark shows me that this host sends an outgoing multicast with a random source port, so that replies from other hosts will be blocked on an incoming random port.

[UFW BLOCK] IN=wlp1s0 OUT= MAC=<> SRC=192.168.1.17 DST=192.168.1.84 LEN=1255 TOS=0x00 PREC=0x00 TTL=128 ID=19980 PROTO=UDP SPT=3702 DPT=57315 LEN=1235

I don't know if firewalls can possibly track UDP multicast sessions.
Alternatively, is it possible to make wsdd use a fixed port as source for the multicast, that can be simply allowed for incoming packets?

[aleasto]

Looks like this should be possible in both iptables and nftables, but probably not as an UFW application profile?

[christgau]

but probably not as an UFW application profile?

That's a question to the UFW community. AFAIK, that's not possible with UFW, but my knowledge is quite limited.

Alternatively, is it possible to make wsdd use a fixed port as source for the multicast

I have to check. AFAIK, there is no requirement that it should be a random port or it is forbidden to use a fixed port from the WSD protocol perspective. I don't right now if ipv4 multicast on multiple interfaces with the same port and address is possible. Nevertheless, using fixed port will limit functionality in the sense that you cannot run multiple instances of the discovery anymore.

[aleasto]

Nevertheless, using fixed port will limit functionality in the sense that you cannot run multiple instances of the discovery anymore.

Yea, that's right... If the port could be specified as a command-line option then we could have GVfs use its own white-listed fixed port, to at least solve one use-case on the Desktop.

@ondrejholy do you not have this issue in Fedora/firewalld?

[ondrejholy]

Discovery works fine for me on Fedora 40 with firewalld enabled using the /etc/firewalld/services/*.xml files.

[aleasto]

The default firewalld zone for Workstation is "FedoraWorkstation" which allows 1205-65535 on both udp and tcp, so you might just be relying on that. Either that, or firewalld has somehow configured nft to be really smart about multicast replies.

[ondrejholy]

Hmm, yes, the default zone is likely the reason it works, but I haven't looked into that closely.

[aleasto]

I went to check what Windows does and indeed Windows Firewall is configured by default to allow unicast replies to multicast/broadcasts:

Windows Settings -> Security Settings -> Windows Firewall with Advanced Security -> Windows Firewall with Advanced Security -> Properties -> Private Profile Tab -> Settings -> "Allow unicast response"

[christgau]

Since the PR has been merged (thanks for contributing, @aleasto), what about agreeing on a number for a fixed source port? According to the IANA list, both 3701 and 3703 (right before/after the assigned 3702) are reserved already. Although I'm not sure, wsdd and those services will ever run on the same machine, it might be safe to use 37020, which is unassigned, in firewall profiles and downstream usages of wsdd.

[aleasto]

My idea was that gvfs would choose some fixed port, like 37020 as you suggest, then other processes which might want to start wsdd can pick other port numbers.

An alternative could be that wsdd gains a dbus-like interface to multiplex one discovery daemon to multiple clients, so wsdd would be the "owner" of port 37020 rather than gvfs.

[aleasto]

@christgau I implemented the second idea! #218

No need for fancy dbus things as the socket interface fits the purpose just as well.