Messages

I am in the same situation and per Zenarmor I need move aware of soon to be deprecated MongoDB and over to Elasticsearch. I too use both repos due to integrations with Home-Assistant.
I will try the Elasticsearch plugin on Opnsense instead of a remote Elasticsearch instance.

Yes, I'm also experiencing the same era every day. I have a support case open with Zen armor and provided them logs recently. No resolution yet on my side.
They recommended I switched to elasticsearch database as they are deprecating Mongo.

RESOLUTION:
Increasing the MTU size from 1492 (longtime setting) to 1500 on my WAN interface and changing the Docker VLAN interface from empty MTU to 1500 as well, resolved the issue for remote clients. They are now able to connect to Plex and the other web apps.
This appears to be related to kernel updates on Opnsense version 25 for FreeBSD 14 compatible.

Related: https://github.com/opnsense/src/issues/235

This looks like it might be related to an MTU size on my WAN and Docker vlan interfaces since upgrading to 25.x.
After some testing, I lowered the MTU from 1492 to 1472 on both interfaces and as a result, one of my remote clients can now connect to Plex via web client.

More Troubleshooting needed...

Thank you all who responded with Enrichening info.!
Whats odd is, remote access to my Plex and my other web apps via ngnix is successful from these ISP's:

✅ Verizon
✅ Comporium
✅ TMobile
✅ Cyber Assets Fzco
✅ Cogent
✅ Palo Alto Networks

However,
For the other users that cannot reach my web-apps via Swag NGNIX behind Opnsense, I see the rdr nat and Wan rule logs reflect their connecting src IP being allowed in live logs...

* I don't see any IP bans in Fail2Ban either for latest tests
* Frontier, AT&T, and FiOS ISP users: get ERR_TIMED_OUT and cannot get to any of my web-apps.
* Disabling fail2ban does not resolve issue.
* Disabling crowdsec does not resolve issue.

For the remote users who cannot access my exposed apps over 443, they get this when doing a 'curl - v' against my URL:

Schannel: failed to receive handshake (35)

I'm left scratching my head.  Any ideas?

UPDATE:

As a test, I switched from Plex remote access manual port forward using 32400 to Swag docker (ngnix) over port 443. Therefore, I properly disabled the remote-access settings on the Plex server and entered my URL under network settings as required.

***It works for me locally, from my cellular phone carrier off WIFI, and also from a work device that's on a full-tunnel VPN out of a Chicago location.
***Also, my other web apps using Swag (ngnix) are fine and remotely accessible as well for me over from all the same remote connections...

HOWEVER, my remote users continue to NOT be able to connect to Plex or my other web-apps via Swag (ngnix) from certain not all, ISP's, it hangs and eventually they get error in browser:

ERR_TIMED_OUT

I see the traffic in the firewall logs WAN interface with rdr rule label and its allowed.
I ruled out fail2ban, crowdsec, and zenarmor as being causes. Issue persists with those services uninstalled and disabled...

Any other ideas?

I tried with NAT reflection enabled and disabled, no resolution.

Toggled these settings:
NAT Rule:
NAT Reflection: Enable / Disabled
Filter Rule Association: Pass / none

Firewall-> Settings -> Advanced
Reflection for port forwards: checked / unchecked
Reflection for 1:1: checked / unchecked
Automatic outbound NAT for Reflection: checked / unchecked
Firewall Optimization: normal

=====
I'm stumped on what broke this after years of no issue...

All seems to point to the Plex side of things, as all looks well and good on the Opnsense side.
But just very much a coincidence this issue started happening right after the upgrade to 25.1 and persists after incremental updates to 25.1.3.

This is my Opnsense settings for Plex NAT and Port Forward, can some validate this for me?
=================
Firewall -> Nat -> Port Forward
From this page click + (add)
No RDR: unchecked
Interface: WAN
TCP/IP Version: IPv4
Protocol: TCP
Source: Any
Source Port Range: any/any
Destination: WAN Address
Destination port range: (other) 32400/32400
Redirect target IP: Plex server internal IP
Redirect target port: (other) 32400
Pool Options: Default
Description: Plex Media Server
NAT Reflection: Enable
Filter Rule Association: Pass

Firewall-> Settings -> Advanced
Reflection for port forwards: checked
Reflection for 1:1: checked
Automatic outbound NAT for Reflection: checked
Firewall Optimization: normal
=================
I posted my issue as well on the Plex forums here:
https://forums.plex.tv/t/plex-remote-access-repeatedly-enabled-disabled-bouncing/910647

Did you set the outside port manually via advanced options to the same port you used for the port forward in Plex?

Yes, I stated this the setup in my earlier post in this thread.

Do you have a Plex subscription?

If not, may not pay to research this too much as they are removing remote streaming as a free option.

Yes, I'm a Plex Pass user for the last 10 years, not the issue.

If your ISP is IPv4 only (as is mine) have a look at my post here: https://forum.opnsense.org/index.php?topic=45612.msg231178#msg231178


This solved many problems for me post upgrade, one of which was the same Plex remote access problem that you're experiencing

Thank you for the heads up...
My IPv6 int setting is still properly set to none. The only other custom setting I have for my Wan interface is MTU size of 1492, which has been in place for several years.

At the very least I would recommend accessing plex via a reverse proxy.  Caddy is a simple reverse proxy to set up and handles certificates etc for you.  Yes you will need a domain and a ddns service (unless you have a static public IP address).

Alternatives are accessing over wireguard/tailscale or some people even use cloudflare tunnels, latter may be against cloudflares ToS but these options do not require any open ports.

If you search the plex and selfhosted subreddits you will find lots of posts on how to do these things and they will all be a step up from forwarding a port directly to plex.

I've been port forwarding 32400 (no relay) for the last 7 years on my same static IP from ISP through Opnsense. So I'm very familiar.

I considered using my existing Swag/ngnix docker and switching Plex to direct on port 443,but I'm concerned about throughout limits with ngnix.

The only thing that changed was upgrading opnsense to 25.1 and now on 25.1.3

Any other suggestions?

Does your ISP use IPv4 or IPv6?

IPv4

After upgrading from the latest 24.x to 25.1.3 yesterday, something is going on with my port forward NAT rule for Plex.
Plex shows remote access connected and green for about 3-5sec ,then it changes to 'Not available outside your network'.

Plex settings has always been setup with manual remote access port 32400.

Checking back on the Plex settings page regularly, it's evident that it's repeatedly flip-flopping, which is also evident with my Tautulli notification that monitors Plex remote access status.

Prior to upgrading my firewall, this was not an issue. All NAT and WAN interface rules are the same and no other known changes...

Changing NAT rule from TCP to TCP/UDP doesn't resolve it, which was a test as I know only TCP should be needed.

I am also not doing double NAT.

What's even more odd, I'm not able to reproduce any remote access issues with the Plex app when I simulate a remote connection on my cell phone cellular network or from a different ISP and geo. However, my remote friend is no longer able to connect the Plex from multiple devices.

Also when monitoring the firewall traffic, I see the inbound connections successfully being established on Port 32400/TCP and nothing's getting dropped.

I'm following this...
But I'm not experiencing this issue on OPNsense 24.7.11_2-amd64 with Zenarmor.
I checked all system logs as well...

Code Select Expand

completed. 861 packages processed. Updating SunnyValley repository catalogue... Fetching meta.conf: . done Fetching packagesite.pkg: ... done Processing entries: ....... done.
SunnyValley repository update completed. 66 packages processed. Updating mimugmail repository catalogue... Fetching meta.conf: . done Fetching packagesite.pkg: ....... done Processing entries: .......... done mimugmail repository update completed. 190 packages processed. All repositories are up to date. Checking integrity... done (0 conflicting) Your packages are up to date. Checking for upgrades (5 candidates): ..... done Processing candidates (5 candidates): ..... done Checking integrity... done (0 conflicting) Your packages are up to date. ***DONE***

What else can I look for to verify if I'm affected