HDHomeRun Connect 4K and QuFirewall

Printers, HDDs, USB/eSATA drives, 3rd-party programs
Locked
User avatar
DDGNY
Getting the hang of things
Posts: 68
Joined: Sat Jan 02, 2016 2:22 am
Location: Cleveland, OH

HDHomeRun Connect 4K and QuFirewall

Post by DDGNY »

I'm running a Plex server on my TS-251+ and recently added a HDHomeRun Connect 4K to my LAN for Live TV/DVR. Ever since, QuFirewall throws a warning just about every hour that "The number of packets denied access has exceeded 30". I did a capture and this is the event that is repeating

Code: Select all

Feb  4 19:49:25 XXXNAS RULE=9 ACT=DROP IN=br1 OUT= MAC=01:00:5e:7f:ff:fa:00:18:dd:08:1b:32:08:00 SRC=169.254.168.151 DST=239.255.255.250 LEN=302 TOS=00 PREC=0x00 TTL=4 ID=60053 DF PROTO=UDP SPT=1900 DPT=1900 LEN=282 MARK=0    
I confirmed that the MAC matches the HDHomeRun's.

SiliconDust's Support site has an article called "UPnP Multicast Send Unicast Recv Test" where it says:

Technical information about the test:
HDHomeRun Setup send a series of SSDP M-SEARCH packets to the 239.255.255.250 multicast group.
If received by the HDHomeRun the HDHomeRun responds with a unicast SSDP response.
The expected response was not received by the PC running HDHomeRun Setup.

I'm not well versed in this type of stuff, and would appreciate any ideas on creating a new QuFirewall rule that doesn't open anything up and eliminates the warnings.
TS-251+: 8GB, 2x6TB WD Red RAID1, Pawtec USB DVD-RW
TR-004: 4x4TB WD Red RAID5
UPS: APC Back-UPS ES 750
neilflix
New here
Posts: 2
Joined: Sun Mar 07, 2021 5:01 am

Re: HDHomeRun Connect 4K and QuFirewall

Post by neilflix »

Hey, were you every able to find a solution for this? Seems like I may be having the same issue.

I just turned on QuFirewall today for the first time and I'm seeing a similar response with regard to the denied packets warning every hour or so from a similar source IP (169.254.1...) and the exact same destination you have. I too have an HD Homerun running on my network which I have running through Plex on my main QNAP server (haven't turned on QuFirewall there yet, want to test run and ensure I understand it on my back-up machine first).

Was really worried when I saw 200+ packets denied in like 10 hours, but I'm hoping its the same issue you've had and not some low-level attack. Thanks!
tigercook
Starting out
Posts: 32
Joined: Mon Nov 26, 2012 11:21 pm

Re: HDHomeRun Connect 4K and QuFirewall

Post by tigercook »

I am also ruining Plex but no HomeRUN, I have the same event in the QUfirewall :P-(
elvisimprsntr

Re: HDHomeRun Connect 4K and QuFirewall

Post by elvisimprsntr »

Your first mistake is using QuFirewall if you want to protect your network and data from attacks.
sfmitch
Starting out
Posts: 11
Joined: Thu Apr 29, 2021 8:33 pm

Re: HDHomeRun Connect 4K and QuFirewall

Post by sfmitch »

@elvisimprsntr Can you elaborate? Is QuFirewall bad?
tigercook
Starting out
Posts: 32
Joined: Mon Nov 26, 2012 11:21 pm

Re: HDHomeRun Connect 4K and QuFirewall

Post by tigercook »

elvisimprsntr wrote: Fri Apr 30, 2021 10:26 pm Your first mistake is using QuFirewall if you want to protect your network and data from attacks.
Thank you for your insightful and helpful comment, I am protected by Cisco Meraki, going for belts and braces with QuFirewall

*********

For others that would like some useful information, i have discovered if you disable, 'local network discovery (GDM)' in Plex it really helps,

I have raised a ticket as QuFIrewall as does not handle multicast very well and have added the following rule - allow 253.253.253.253/32

take care and be kind to each other :-)
steventoney
First post
Posts: 1
Joined: Mon Apr 05, 2021 3:38 am

Re: HDHomeRun Connect 4K and QuFirewall

Post by steventoney »

tigercook..

how did you enter that subnet mask?? in adding a rule on ip subnet it will only allow a pulldown set of selections - most are variants of 255.255.255.255...........it will not allow the 253.253.253.253 subnet overlay as a choice...... I used the "include subnet only" profile as a starter set of rules and trying to see what is denied. most are local broadcast for DHCP - SSDP - NBNS on the 253.253.253.253 src.. the rule making interface is pretty crude and there glitches in the capture events areas. reading the pcap file with wireshark -- is easy but the pcap files do not seem to contain what I would expect. often showing older events and not those during the capture time frame on the NAS running qufirewall

thanks
tigercook
Starting out
Posts: 32
Joined: Mon Nov 26, 2012 11:21 pm

Re: HDHomeRun Connect 4K and QuFirewall

Post by tigercook »

if you use a /32 mask this equals a single host, i am not 100% sure its working, i get ~60 traps every 30 mins, have altered the email trigger so i will know if a ture threat or not outside of this baseline, i hope Qnap can fix multicast packets through the FW....
You do not have the required permissions to view the files attached to this post.
tigercook
Starting out
Posts: 32
Joined: Mon Nov 26, 2012 11:21 pm

Re: HDHomeRun Connect 4K and QuFirewall

Post by tigercook »

always worth creating a ticket, things get fixed! -

response from support
The issue of QuFirewall blocking 253.253.253.253 has confirmed and will be fixed in the future version, probably the next version, but not confirmed yet.
You may try the new firmware when it is released.
Adding the rule for 253.253.253.253/32 as you did should be enough until the new version is released.

keep an eye out here

https://www.qnap.com/en-uk/app_releasen ... qufirewall
tigercook
Starting out
Posts: 32
Joined: Mon Nov 26, 2012 11:21 pm

Re: HDHomeRun Connect 4K and QuFirewall

Post by tigercook »

looks like its fixed, I no longer get false possessives, hope this helps?

QuFirewall would display a large number of warning messages (about the denied broadcast packets from the IP address 253.253.253.253) due to a change in the name of virtual interfaces.

https://www.qnap.com/en/release-notes/q ... 0/20211201
lwesker
New here
Posts: 8
Joined: Mon Jun 11, 2018 8:19 am

Re: HDHomeRun Connect 4K and QuFirewall

Post by lwesker »

I noticed some things within DDGNY question that no one else replied to. But first, for all seeing similar issues, these alerts are unlikely to be an attack by a bad actor device.

SRC=169.254.168.151 -- This indicates the HDHomeRun did not acquire a IP Address from the DHCP server, nor did it get configured with a manual IP appropriate to its subnet. If see anything in anything in 169.254.x.x range you need to troubleshoot why the device could not reach your DHCP (the router for most people). This as will cause your device to misbehave in other ways.

DST=239.255.255.250 DPT=1900 -- This is a Multicast destination for SSDP used by UPnP. It is well known that UPnP is not safe and should be turned off in your routers, so you may want to configure the HDHomeRun not to try and access UPnP, as in a secured network, no one should ever reply. Although I notice one reply above mentioned this may be how multiple HDHomeRun identify themselves to each other, IDK.

Anything in range 224.0. 0.0 through 239.255. 255.255 is multicast (so 224.0.0.0/4). Don't know why some replies got sidetracked on 253.253.253.253. Off topic to poster's question.

Ignore anyone saying "Why do you use QuFirewall blah blah blah". Troll bait. Its like saying to people living in gated communities, "Why do you lock your front door at night? The front gate and local security will prevent bad guys from entering your house." How naïve.

QuFirewall is a zero-tolerance by default firewall. No pre-defined assumptions by the software programmers what is safe on your network. Unlike so called "easy to use firewalls". So of course it needs advanced IT knowhow to understand its value and how to configure. It is not a bug when QuFirewall sends alerts on any message it receives (which includes broadcasts and multicasts) that the QNAP Owner has not previously configured as trustworthy.

You're not alone. Took me a full day to finally find all the causes and add trustworthy rules, to get my nominal alert rate down to zero. It's worth it, because anytime QuFirewall flares up now and flags an alert, I find something has gone awry on my network that needs attention.

As an experiment, I created rule "All 1900 UDP Any Deny". Started seeing that every computer in my house is sending SSDP multicasts. Previously QuFirewall not alerting because I have the rule:
All Any Any (my local subnet) Allow
Trusting all (and only the) devices in my local network to talk to the QNAP.

To eliminate the alerts means you're telling QuFirewall you trust 100% of the time in the future that that action is safe. If so, may I suggest you create rule:
All 1900 UDP 169.254.0.0/16 Allow
This tells QuFirewall to also accept any SSDP from devices in the no-dhcp-assigned address range.
Locked

Return to “Hardware & Software Compatibility”