Hello All,
Strange issue. I have a HD Homerun and I want to connect my Plex Media Server to it. The problem is Plex Media Server is in a K3s on Truenas and cannot autodetect any device outside of the local subnet. It is (HD Homerun) connected to the IoT network just fine and I can access it, but Plex Media Server cannot. I pretty much have default standard firewall rules for my different subnets and everything works fine.
My Question to you Wizards is: Is this an OPNsense firewall rule issue or a Truenas K3S issue? If OPNsense is there a firewall rule you can steer me towards?
HDhomerun ip 192.168.3.77
Truenas Plex Ip: 192.168.1.48:32400
router ip: 192.168.2.100
I suspect this is a Truenas issue, but probably somebody here has encountered this before locally and it may be a OPNsense firewall blocking cross subnet auto ip detection / connections.
Appreciate the help.
Since you can enter the HDHR IP, you don't have to deal with enabling discovery (apparently via a broadcast relay).
As you connect, I would look at the FW live view filtered down to that destination IP and enable the identified traffic.
Streaming seems to involve UDP 5004. Discovery/Control on UDP 65001?
I'm running SiliconDust HW and SW across the board, and I've put all devices involved (tuner, DVR, fire cubes) in the same VLAN...
I'm fairly sure this is a HDHR issue. I had this problem years ago with HDHRPrime. I couldn't find an easy solution at the time and had to have devices accessing HDHRP on the same subnet. Maybe SiliconDust have fixed this now.
Before I replied, I had done a quick search. There's apparently plenty of people that have Plex and the tuner in separate VLANs.
It's apparently more difficult with the SiliconDust DVR because this one relies entirely on discovery via broadcast.
At least Plex lets you enter an IP for the tuner... So tuner discovery is out of the way.
Figuring out the rest should be simpler.
Try mDNS or UDPBroadcastRelay.
Here's mine, I have plex on my IOT VLAN but devices on my primary VLAN can see it. You'll likely need a rule to allow the PLEX server to send the streams to the primary VLAN.
Relay Port 5363
Relay Interfaces Pri, IOT
Broadcast Address 224.0.0.251
Source Address 1.1.1.1
Instance ID 2
Use TTL for ID YES
Description mDNS
I wanted to say thank you for the help. Lots to digest here, but I will start with the Firewall rule marjohn56 recommended and respond.
Quote from: EricPerl on February 22, 2025, 03:36:06 AMBefore I replied, I had done a quick search. There's apparently plenty of people that have Plex and the tuner in separate VLANs.
It's apparently more difficult with the SiliconDust DVR because this one relies entirely on discovery via broadcast.
At least Plex lets you enter an IP for the tuner... So tuner discovery is out of the way.
Figuring out the rest should be simpler.
I think my local situation is probably making this more complicated than it needs to be. I am using the AdguardDNS plugin so I have to look into how the mdns solution can play nice with both operating right now. The mimugmail version of adguard on opnsense is extremely simple to install and get working, but how it plays with mdns will have to be trial and error. To be clear manually entering the ip address of my HDhomerun works for all devices (even IoT devices with no trust status), except the stupid plexmediaserver plugin on Truenas. Its got to be that k3s setup. I will try Plexmediaserver as a docker and see if that solves it first. THe mdns rule I tried did not work, but I will admit I'm a total noob with mdns as of 5 minutes ago learning about it.
Did you install the os-mdns-repeater plugin? It's pretty easy to configure. Just tick all interfaces that should be visible to each other via mDNS. If you have e.g. an "allow all" rule on LAN nothing else needs to be done for devices on LAN to see mDNS capable devices on all other networks you ticked.
I did install it and it appeared to install fine. It didn't solve the problem, but this is not an OPNsense problem at this point. Sorry to waste your time.
Its a Kubernetes problem / Truenas problem that fights you tooth and nail whenever you try to do simple basic networking stuff.
I cannot understand why I can access my HDhomerun from EVERY device in the house via its IPaddress but Plex cannot and will not do so even when I enter it manually.
I then started down trying to install plexmediaserver within dockge, which resoundedly defeated me in trying to mount network media via docker compose. Sigh.
Chatgpt is clueless and incorrect.
This is a (me) / Truenas problem gentlemen. Us normies just can't have nice things. Appreciate the help. OPNsense is working great.
There was evidence in online posts that mDNS was NOT used.
A pure broadcast seemed to be used for discovery.
But discovery is out of way since the OP can specify the IP.
From that point on, I would think that observing FW traffic should be enough.
Arguably, Kubernetes + Truenas add complexity.
This said, observing some traffic entering the FW (interface of Truenas) would indicate that part of the setup is correct.
It's obvious the issue is at the source if there's no traffic.
Reply traffic is more difficult to observe (packet capture) but it shouldn't be rocket-science after the request traffic is identified from the previous step.
"There was evidence.."? I don't understand the post. Tell me what else I need to install to make mDNS "installed". Pic related is what downloading the plugin creates on 25.7 appears to look like.
I tried every possible permutation of the ip4 subnet argument point. Leaving it blank does nothing else. My truenas server is 192.168.1.48 with PLex on port 32400. The HD Homerun is on 192.168.3.77 (different subnet) no idea on the port it uses.
Putting your devices on the blocklist might not be the proper way, I think.
Anyway, I don't know HD Homerun, but according Wikipedia it uses DLNA.
I struggled to get DLNA working across pfSense and connect my TV to the server years ago. The DLNA server runs in an LXC. I then put it into a separate VLAN and bridged it on the router to the IoT subnet, where my TV is connected to.
From the TV I had to allow TCP/UDP 1900 + 8200 to the DLNA server and UDP 1900 to 239.255.255.250.
So the TV advertises its presence via SSDP obviously.
Hence, maybe you can also get this work with the UDP Broadcastrelay plugin. I never tried. But you will need to set the broadcast IP to 239.255.255.250 and the port to 1900 then.
Quote from: Mark_the_Red on February 24, 2025, 10:01:25 PM"There was evidence.."? I don't understand the post. Tell me what else I need to install to make mDNS "installed". Pic related is what downloading the plugin creates on 25.7 appears to look like.
I tried every possible permutation of the ip4 subnet argument point. Leaving it blank does nothing else. My truenas server is 192.168.1.48 with PLex on port 32400. The HD Homerun is on 192.168.3.77 (different subnet) no idea on the port it uses.
My cursory research on Plex HDHR comm indicated that mDNS is not used.
Instead, the discovery relied on a UDP broadcast. A broadcast relay would be necessary for that.
But again, since you can input the IP, discovery is irrelevant (FWIW, the HDHR DVR does not have that feature).
I already posted about ports used, again based on cursory research.
But I wouldn't create rules purely based on that research, because it lacked depth and consistency (possibly because of different HW or versions).
It's not that hard to look at the FW live view as you attempt to connect.
You have the destination IP on top of it. You can filter down if there's too much noise.
If traffic is blocked, create a rule to allow it.
At some point, you should see a IN request on the interface corresponding to plex, followed by an OUT on the interface corresponding to the tuner.
If you see that but nothing really happens on Plex, you'll need to hunt for reply traffic with packet captures (interfaces > diagnostics).
Just as an update, some super helpful guy over on Plex explained the problem pretty well and how what I am experiencing is expected.
https://forums.plex.tv/t/live-dvr-plex-media-server-cant-detect-hd-homerun-over-different-subnet-to-server/906937/2
Neither him nor I could explain why my firewall doesn't show ANY traffic between subnets for this process when watching the live view. I am just not qualified at this time to delve into the why or how within OPNsense over a relatively peripheral network need right now. I am sure its some obscure Linux permission issue on Truenas or the k3s environment regarding ports.
Just thought I would share this here as the Plex expert explained in good detail the network protocols plex / hdhomerun use to communicate to each other.
Can you see and use the Plex server from a device on the same VLAN as the Plex server? If yes then there is no reason why with the use of UDPBroadcastrelay and a firewall rule you cannot get it to work across VLANs.
He explained how pure discovery failing is expected (the help mentioned is a broadcast relay).
Once you enter the IP, he seems at a loss to explain why (it worked in his test).
The live view screenshot shows out traffic only (all destined to Plex), possibly from streaming clients.
As you press that connect button on Plex, you should see in traffic on that interface (source being Plex).
Per Plex thread, standard HTTP.
Share your rules on that interface. Maybe you don't have logging enabled.
THanks guys. I was away this weekend at my sons hockey tournament. My original post has the metwork mapped out so these are PHYSICAL interfaces controlling the subnets. Logging is set to whatver the Vanilla OPNsense factory settings are.
Interface 1: Server (Plex Media SErver is IP address 192.168.1.48:32400)
Interface 2: IoT (HDHomerun is ip address 192.168.3.77)
Pic related is my IoT rules. Don't bully me if I cannot keep NSA glowies out of my system like you guys can with special elaborate rules; I followed this guys firewall rules system to a letter https://www.youtube.com/watch?v=TjXkWSjYqlM&t=1s Seemed logical and correct.
Here's how I read these:
Rule #1: Allow IOT Net to access the DNS server at IOT address (OPN hosted, Unbound or AGH or whatever). Very typical.
Rule #2: That's an IN (from the perspective of the FW) rule on the IOT interface and your TRUSTED RIG is probably not on that network so it won't be a source. This rule likely never fires.
Rule #3: Same? I'm not sure why your "work" devices would be on the IOT network. These devices are not depicted in your OP.
Rule #4: Allow access to the internet from the IOT interface (the source might as well be IOT_net. exceptions exists but unlikely in your case).
It's not blocking anything BTW.
The last rule is not enabled so I ignore it.
None of these rules are logging anything... the i is grey. If you want to see artifacts in the logs or live view, you need to enable logging.
When Plex tries to communicate with the HDHR device, you should see traffic hitting the SERVER interface first (IN) and if that's allowed, you should see OUT traffic on the IOT interface. The general consensus is the control traffic on the interface where the source resides (IN rule on the SERVER interface for you).
IN and OUT are from the perspective of OPN.
Quote from: EricPerl on March 05, 2025, 11:41:02 PMHere's how I read these:
Rule #1: Allow IOT Net to access the DNS server at IOT address (OPN hosted, Unbound or AGH or whatever). Very typical.
Rule #2: That's an IN (from the perspective of the FW) rule on the IOT interface and your TRUSTED RIG is probably not on that network so it won't be a source. This rule likely never fires.
Rule #3: Same? I'm not sure why your "work" devices would be on the IOT network. These devices are not depicted in your OP.
Rule #4: Allow access to the internet from the IOT interface (the source might as well be IOT_net. exceptions exists but unlikely in your case).
It's not blocking anything BTW.
The last rule is not enabled so I ignore it.
None of these rules are logging anything... the i is grey. If you want to see artifacts in the logs or live view, you need to enable logging.
Appreciate the help. I enabled logging and did not see anything on either server or IoT interfaces. I can pretty much conclude that it is 100% the kubernetes truenas application that is blocking this connection as the attempt to connect / discover the device is not even making it to the firewall. I'm going to have to put on my big boy pants and learn how to docker compose a proper Plex Media Server.yml via jailmaker if I ever want to get this working. So far I've failed miserably at doing this due to various bugs I can't discern.
I don't want to sidetrack the thread, as to the firewall rules. But to your questions:
Quote from: EricPerl on March 05, 2025, 11:41:02 PMRule #3: Same? I'm not sure why your "work" devices would be on the IOT network. These devices are not depicted in your OP.
I have one access point in the house on a single SSID (you are right its not on the flow chart but basically anything wifi is connecting via IoT network subnet).
My laptop and my wifes laptop are static IP's assigned to this TRUSTED_LAPTOPS alias that can basically go anywhere in my local network. I have my reasons for doing this, but mainly has to do with 4 teenage or teenage children in my house with infinite devices all connecting, their friends,etc. My main goal is to block porn/dark internet bad shit access from my Wifi for them via Adguard home. Yes I know some people can get around this using cell networks (not my kids due to MDM on their phones) but thats another parents problem, not mine as far as I am concerned.
I have my reasons for setting it up like this, in that I trust firewall rules over my knowledge of implementing VLANS (total noob). Basically any device on my wifi that isn't manually assigned to Trusted Laptops (Alias) can only use the DNS server (adguard) to get to the internet.
I assume you think I am nuts. From reading the how to's here and reddit, everyone is saying to have multiple SSID's for wifi, multiple VLANs, etc and manage all the cross talk via the VLAN permissions? I just think policing the TRUSTED ALIAS firewall rule is easier and fits my needs just fine (its only 4 devices tops). I checked it from multiple devices not on the TRUSTED_LAPTOPS alias on my wifi and they cannot access my server (unless through plex).
Managing multiple VLANS over trunk interfaces, multiple SSID's, etc. seems like way more work and overhead, and nightmare fuel for me to debug if something breaks with a future Windows 11 update, etc. Probably childs play for a guy like you, but I like this way because its easier (for me) and the youtube (Home Network Guy) video convinced me it works. It does work now as far as I can see.
Quote from: EricPerl on March 05, 2025, 11:41:02 PMRule #4: Allow access to the internet from the IOT interface (the source might as well be IOT_net. exceptions exists but unlikely in your case).
It's not blocking anything BTW.
Do I have to define which networks it has to block? Basically I don't want anything on that IOT (192.168.3.x) subnet being able to connect to my main rig (192.168.2.x) and server (192.168.1.x) subnets. IT appeared to me the Private Networks alias is an industry standard term for anything with a 127, 192, 10, subnet. I don't care what I have to type here but is an alias I make called 192.168.2.0, 192.168.3.0 better?
If you don't see the expected IN traffic on the interface corresponding to Plex (Live view is sufficient for requests, you can also resort to packet captures), it indeed suggests that the request does not make it out of your host.
In some cases, I've resorted to port mirroring on the switch the machine is connected to, but it does not seem to be necessary.
If you can afford it, there are small mini-PCs that are Plex capable for less than $200 nowadays.
Even as a test, as the machine can be repurposed.
You do you with how you handle your network. I'm not judging.
I might just suggest different names because terminology has meaning...
While I'm still fairly new at networking, I've been working in computer security for most of my career so I tend to do things using established mechanisms.
Wrt rule #2, I stand with what I wrote if TRUSTED_RIG (2.x) is not on the IOT network (1.x).
Traffic originating from TRUSTED_RIG will get IN the FW on the 2.x interface.
So rule #3 gives unlimited access to your TRUSTED_LAPTOPs (Internet and other VLANs) while rule #4 grants the rest of IOT devices access to the internet only.
That's fine (as long as you don't mind all these devices potentially trying to compromise your laptops. That's what proper isolation would get you).
My comment wrt blocking about rule 4 was primarily targeted at the comment.
This allow rule will never block anything, by definition. It does not allow some traffic. Another rule might...
Here, it's currently the last custom rule, so the next rule is the default deny. That's the one that blocks.
I appreciate the help. I am fairly new to OPNSense and came from Ubiquiti, so please excuse my dumb questions sometimes. My reason for this thread was to see if I was missing something obvious to OPNsense and Plex because I know these are very popular applications for people with this type of enthusiast equipment equipment.
It appears my firewall is not the problem so I am missing creeping the topic a bit. My reason for the follow up is "you don't know what you don't know", so if what I was doing was crazy, I pride myself on not being stubborn with tec, so I am more than willing to change.
Learned from you guys that I wasn't enabling the logging, and per your email what you wrote is correct:
Quote from: EricPerl on March 15, 2025, 02:30:45 AMWrt rule #2, I stand with what I wrote if TRUSTED_RIG (2.x) is not on the IOT network (1.x).
Traffic originating from TRUSTED_RIG will get IN the FW on the 2.x interface.
As you wrote, it was a useless rule, so i deleted it. I thought (incorrectly) that I needed to give the interface IoT an opening for my trusted rig to access those devices. Not sure what I was thinking. This is my first real firewall setup on OPNsense.
On that note, I am trying to enable some kind of DoH blocklis. I had this enabled on my edgerouter and it was great; I couldn't believe how much nefarious stuff out there is daily trying to probe your router. Wasnt sure how to implement something similar on OPNSense. Not asking you to do my research for me, but since you are a security specialist, you might share a link to someone implementing this on OPNsense. Or do I use Adguard Home as the platform for this?
https://github.com/dibdot/DoH-IP-blocklists
Appreciate the help BTW.
You should probably start a new thread. I just use AGH and crowdsec at this point, based on info gleaned from the forums.
There's nothing you can do about probing. That's why you have a firewall. I don't know how much you allow IN from WAN (nothing is best. the more you allow, the more you take risks).
Blocklists are dealing with ads and outgoing traffic.