firewall ports, again

[white_haired_uncle]

I did see the firewall ports in FAQ, though the link seemed to be primarily intended for SD DVR users. Wasn't sure if I should pollute that thread with my questions, guessed not.

Working with a FOSS DVR that uses libhdhomerun, on Fedora 42 which runs firewalld by default. Didn't work out of the box. I have it working, but it doesn't seem right to me so I'm not confident I have it working correctly. I finally ended up pulling out wireshark to figure out how to get hdhomerun_config discover working. It seems 65001/udp is the SOURCE port. I can kind of see the rationale for filtering on source ports < 1024, but this just makes no sense to me. All of the other rules open (usually) a single destination port, which makes sense. AFAICT, if I filter on source port I'm effectively opening ALL destination ports, at least for one host, which kind of defeats the purpose of filtering at all. This "works", in that discover succeeds:

Code: Select all

sudo firewall-cmd --add-rich-rule 'rule family="ipv4" source mac="00:18:DD:06:8D:74" source-port port="65001" protocol="udp" accept' --zone=public --permanent

It's a home environment, so I don't care so much about the security aspect (if someone is in my house and has had the time to clone the MAC of my HDHR I've got bigger problems), I'm more concerned that I'm doing something wrong.

I'm also confused as to why data transfer, which appears to consistently come FROM 5004/udp, is successful, but I haven't really dug into that one yet.

[jasonl]

Discovery sends out from a high UDP port that is assigned by the OS to 65001. The HDHomeRun replies from 65001 to that high port. Smart firewalls recognize that the unicast response is related to the previous broadcast and allow it through. The Google machine says it's possible to use the 'ct state' module of nftables (the backend of firewalld) to allow this. Hopefully that gets you started in the right direction, as I'm not familiar enough with the RedHat universe to give you anything more.

[white_haired_uncle]

Thanks. It looks to me like it's the broadcast that keeps things from working out of the box. Even with connections from the HDHR open, I still see the discover connection as "unreplied" (as compared to a DNS query, which is I forget what but not "unreplied"). From what I've read, connection tracker matches out/in packets using the same pairs of ip/port, with no mention I can find of an exception when the initial connection is a broadcast, and of course on a broadcast the IPs won't match. I don't know why dhcp works, didn't look at it.

I suppose I could spend some hours and probably get it to work, but I'm never going to put in enough time to really know that what I came up with is correct. Hopefully a network expert will come along and chime in.

Thanks again

[rikd]

Thanks. It looks to me like it's the broadcast that keeps things from working out of the box. Even with connections from the HDHR open, I still see the discover connection as "unreplied" (as compared to a DNS query, which is I forget what but not "unreplied"). From what I've read, connection tracker matches out/in packets using the same pairs of ip/port, with no mention I can find of an exception when the initial connection is a broadcast, and of course on a broadcast the IPs won't match. I don't know why dhcp works, didn't look at it.

I suppose I could spend some hours and probably get it to work, but I'm never going to put in enough time to really know that what I came up with is correct. Hopefully a network expert will come along and chime in.

Thanks again

AFAIR the default config for firewalld allows services to connect to ports less than 1024, and blocks everything above 1024.
So that will allow DHCP to work as well as any service that uses ports below 1024 like SSH, etc.
The streaming from port 5004 will work because it's initiated by the DVR opening port 5004, and sending a HTTP GET to the HDHomeRun's IP. THe HDHomeRun will then respond with a packet sent to the DVR on port 5004. The firewall uses connection tracking (because an IP and PORT are provided) to allow the response back from that IP:PORT back to the app.
Broadcast doesn't work like that though since anyone can send to the broadcast address, hence even though the DVR can send the DISCOVER packet out, there is no connection in broadcast so no connection tracking to allow packets back - hence you need the rule.

[nickk]

The rule is to allow the incoming (to the PC) discovery response.

The source port (the HDHomeRun) is fixed = 65001.
The destination port (the PC) is random and can't be used in the firewall rule.

[rikd]

my bad.. updated post.. the rest about connection tracking is correct.