Quote from: viragomann on August 01, 2025, 12:05:49 PMYou can also run a traceroute from the Plex server to the TV.
I can run traceroutes to all of the addresses of these devices, results are similar: TTL 1, AS0, < 1 MS for hard line devices and 5-6 MS for wifi devices (unless I use ICMP, then its ~20 MS for the TV but still ~0.3 MS for the server).
If I try to specify any device other than a gateway as the source address, I get an error "traceroute: bind: Can't assign requested address".
Quote from: viragomann on August 01, 2025, 12:05:49 PMWithout knowing, what you did exactly with port forwarding, what you need and what you see exactly on the OPNsense interfaces, there no possibility to give any help.
I believe I have narrowed down the issue, and I think it was actually an issue with the server's routing tables.
Two VLANs (IOT and MGMT) fail to return packets back after the connection is forwarded. These are the only VLANs with connections to dockers running tagged traffic through a separate NIC on that server.
- The server runs Home Assistant (and some related docker services) on the IOT subnet/VLAN. Almost all other devices on this VLAN are wireless, on a dedicated SSID. I would prefer TVs to be on this VLAN as they are talkative and participate in automation routines (on the dedicated tagged traffic NIC). From what I've read, it gets incredibly complicated to try to run this on another VLAN than the IOT devices themselves, and some devices just cannot see the coordinating services unless they are on the same subnet.
- The server runs Omada controller on the MGMT vlan (on the dedicated tagged traffic NIC).
- All the server's untagged traffic should be going through the default NIC, which is then tagged by the switch on the SERVER VLAN.
I can connect to the server directly from these VLANs, but it is definitely slower. I had not observed this, because the only use case that exposed the issue was the forwarded traffic.
I am thinking that the server is trying to send the untagged responses to these requests over the tagged traffic NIC? What was throwing me off, is that the forwarding was working and showing blocked connections in the logs that made me think it was a rules issue.
The server's had some automatic entries in the routing tables that were created when I set up the VLANs. These were /24 ranges and include the devices that I am having issues connecting from. I was afraid to mess with this, as I don't know much about it and have had difficulty finding resources that make sense to non-IT professionals.
It looks like I may have fixed the issue by replacing the /24 range with more specific ranges that no not overlap with the devices outside of the server. Does this sound right? It need only cover the range of required LAN IPs for the local services that take a non-default route to the VLAN NICs?
This raises a couple more questions for me:
- Do I even need a routing table entry for the docker if it is explicitly set to use that NIC?
- What about IPv6? I have a dynamic ipv6 prefix, how to I avoid overlap with other devices on IPV6 (I know plex doesn't use IPv6 but I am worried about all the IOT devices that do and may have been having issues with server connections).
Thanks again viragomann, for you input and patience. I will mark this as solved if everything is still working in a few hours.
Any more wisdom, suggestions (even eye rolls at my lack of expertise) is welcome and appreciated! It's worth a lot to be able to put the issue out to the forum because you don't know if there's a known issue or fix that you never would have thought of even through spending a few weeks searching the forum, reddit, googling, or chasing other rabbit holes.
If you can point me to any good resources or tips for novices to understand what entries are commonly required in linux routing tables for a home server with a couple VLANs and ipv6, I would appreciate it.