For a few months now, I have been trying to figure out why port forwarding is being blocked for a certain VLAN. Please forgive me, I am novice.
I decided to wait until updating to 25.7 to see if the issue persists, and it looks like it does.
I assume I am missing something, but here is what I am observing:
- Plex server connects to my 'servers' VLAN
- I have port forward rules for plex to forward the designated plex ports to the server and correct port
- This works for another VLAN (USER), just not my IOT VLAN
- I have even mirrored the firewall rules exactly for the USER VLAN and the IOT VLAN. USER works, IOT does not.
Devices on the IOT are generally connecting through the same WAP on an SSID tagged for that VLAN. The same device reconnected to the USER SSID and associated VLAN connects no problem. This happens with both VLANs sharing the same forward rule, and any phones, TVs or other devices I can toggle between VLANs.
It looks like port forwarding is working... When I look at the live log filtered by destination port for the plex server, I see a lot of default deny rules for the server, so the requests are being forwarded. Traffic from this network is denied, and I cannot figure out why.
I am seeing blocked traffic in the firewall logs originating from the IOT VLAN with the forwarded server IP and port:Screenshot 2025-07-30 152917.png
Traffic is forwarded from other VLANs and WAN using identical rules except for the source, not blocked.
I have tried allow all rules for the IOT vlan and the IOT devices (they should not be required and it used to work without them).
Any suggestions?
Apologies, right after posting this I saw it is in the VPN forum, which I misread when looking for the appropriate category, and don't see an option to change. Please delete or move to the appropriate channel.
It's hard to get an idea what's wrong, if you hide all relevant information.
I suspect, that OPNsense doesn't have a proper state for the blocked packet, i.e. that it's not an SYN packet.
Klick the "i" icon on the right and check out the TCP flag.
If it's not a SYN packet, you've probably an asymmetric routing issue. This often happens with VLANs, when a device is leaking the traffic between the subnets.
Thanks Viragomann!
Edit: figured out my image difficulties... the 'insert' button can hide behind a dark image.Screenshot 2025-07-31 135358.png
The source IP is the local IP4 of the TV with a random port.
The destination is the Plex server local IP4 with the plex port (which is forwarded from another non-standard WAN port).
- The TCP Flag is 'R'
- Ipflag is 'DF'
I'll start looking into asymmetric routing and I'm happy to grab any other info. Thanks very much in advance for anyone taking the time and consideration on this.
Quote from: QS-Data on July 31, 2025, 09:23:20 PMThe source IP is the local IP4 of the TV with a random port.
The destination is the Plex server local IP4 with the plex port (which is forwarded from another non-standard WAN port).
- The TCP Flag is 'R'
'R' is just reset.
So the TV sends a reset to the Plex server, but OPNsense is not expecting this packet. A Reset could be sent at any time due to various reasons. It's not necessarily due to asymmetric routing. But I think, if OPNsense had a state for this connection it shouldn't have blocked it.
Check out if the route from the server to the TV properly goes to the firewall.
You can also sniff the traffic using the packets capture utility on OPNsense to verify if both directions of the communication pass the router.
Quote from: viragomann on July 31, 2025, 10:27:03 PMCheck out if the route from the server to the TV properly goes to the firewall.
Is there a another way to do this other than packet capture below?
Quote from: viragomann on July 31, 2025, 10:27:03 PMYou can also sniff the traffic using the packets capture utility on OPNsense to verify if both directions of the communication pass the router.
Trying this, but I am not certain what is conclusive... It looks like nothing is going from server --> TV.
Packet capture of any items with {Tv IP4} AND {Server IP4} produced zero packets originating from the server, but packets from the TV to the firewall, and the firewall to the server. Yellow mac address is the firewall, blue mac and IP are TV, green mac and IP/port are server:Screenshot 2025-07-31 174553.png
Not sure if this could be related, but something came to mind. A distinct characteristic of the IOT VLAN in contrast to the USER VLAN, is that the server running plex also runs home assistant in a container that uses a separate NIC to connect to the IOT VLAN.
Thanks again for looking at this!
Quote from: QS-Data on August 01, 2025, 02:04:07 AMQuoteCheck out if the route from the server to the TV properly goes to the firewall.
Is there a another way to do this other than packet capture below?
You can also run a traceroute from the Plex server to the TV.
Quote from: QS-Data on August 01, 2025, 02:04:07 AMPacket capture of any items with {Tv IP4} AND {Server IP4} produced zero packets originating from the server, but packets from the TV to the firewall
Without 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.
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.