Firewall Rule - Plex Media Server - Accessing HD Homerun on Different Subnet

[EricPerl]

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.

[Mark_the_Red]

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.

[EricPerl]

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.

[EricPerl]

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.

[Mark_the_Red]

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.

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:

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.

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.

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.

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?

[EricPerl]

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.

[Mark_the_Red]

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:

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.

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.

[EricPerl]

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.