plex
-
-
You only need to portforward the TCP port 32400.
DLNA and GDM are for discovery inside your network.Also, as you are already doing a portforward, you don't need UPnP.
Can you confirm if you have a public IP in your modem ? Suspecting that you have something like a CGNAT, providers are doing that a lot lately..
Yes I have a public IP right now. Something I am hoping to change in the future when I change providers. Not sure when that will be though. Thanks for the info regarding the other port forwards, you are correct. They are not really necessary.
@panzerscope plus this would never work anyway
How would your plex server IPs be source to your Plex server IPs?
And your wan rules are just wrong.. The destination on your wan rule would be the IP of your plex server.
You need 1 rule as @mcury mentioned.
And there is zero reason to hide your lan side rfc1918 address. Here is my setup..
I use a different outside port. But just think that is also 32400
I limit what geo based IPs can access mine with a pfblocker alias.. But I would really suggest you just get it working before you put in any sort of restrictions.
I have gone ahead and disabled all the other security packages for now to remove them as any sort of factor and make sure the basics are correct.
So if I understood your advice correctly, my WAN Rules now look like the below for my Plex:
The overall config page for that rule looks like the following:
My Plex NAT Port Forward looks like the following:
I use 32400 for both internal and externalThe overall config page for that rule looks like the following:
Is this correct or did I miss a trick ?
Thanks very much.
-
Is it working? I just at a loss to why you would create aliases for 1 port and 1 IP.. Just another thing to get wrong, and is the alias working.. We have no idea what you put in there.
-
Well it is "Working" so far as I can access my Plex media via my phone using mobile network, I can also play the media. However I can do this even when Plex is stating that the connection to the outside internet is not available. This was how it was working before with the first configuration I started with at the beginning of this topic.
It can still work fine like this, up until a point where I can no longer access the plex media on my phone/outside network. I don't change anything during this time, it just happens as it were.
For clarity, I have removed the ALIAS details.
This is my WAN Rule
This is my PF Rule
Thanks!
-
@panzerscope well what does it show for your connection on the dashboard or in your client.
Little circle with ! in = bad, indirect. Little greenpadlock = good, direct
If from the public internet you can not directly talk to your server, you will have an indirect connection, bouncing off the plex servers in the sky... This is going to be limited to 1 or 2mbps be it your pass holder or not with plex. When your direct, your upload is limited by your isp connection upload and your clients download speed only.
https://support.plex.tv/articles/216766168-accessing-a-server-through-relay/
edit: here is someone streaming off my server now.. You can see they have a direct connection showing. And they are exceeding the relay bandwidth limit..
-
@panzerscope well what does it show for your connection on the dashboard or in your client.
Little circle with ! in = bad, indirect. Little greenpadlock = good, direct
If from the public internet you can not directly talk to your server, you will have an indirect connection, bouncing off the plex servers in the sky... This is going to be limited to 1 or 2mbps be it your pass holder or not with plex. When your direct, your upload is limited by your isp connection upload and your clients download speed only.
https://support.plex.tv/articles/216766168-accessing-a-server-through-relay/
edit: here is someone streaming off my server now.. You can see they have a direct connection showing. And they are exceeding the relay bandwidth limit..
Thanks, as expected it does state that it is an indirect connection! Which makes sense considering the below.
Just a little stumped as to what is getting in its way.
-
@panzerscope first thing I would do is actually validate traffic is getting to pfsense from internet.
Go to like can you see me . org, do a simple test.
Using your 32400 port in your case. Does that show valid success?
If not, then sniff on pfsense (diagnostic menu, packet capture) wan when you run the test.. Do you see the traffic get to pfsense wan?
If shows packets getting there, but not success on the test.. The do the same test again sniffing on your lan side interface.. Do you see the traffic being sent on to your plex IP.. 192.168.1.10 ?
Your not using a vpn client setup in pfsense are you - routing all traffic out a vpn connection? Are you using say IPS in pfsense?
So you show your rule being evaluated? In your wan rules do you see something in the states column other than 0/0
Do you have any rules in the floating tab?
-
Ok so I ran the port check on the aforementioned site and it fails with a connection timeout as below:
I did a packet capture while doing this, but seemingly nothing came through that was recognisable, see below :
12:25:03.951326 IP 162.125.64.14.443 > 192.168.0.1.13692: tcp 0 12:25:03.951406 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.951408 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.951526 IP 162.125.64.14.443 > 192.168.0.1.64306: tcp 0 12:25:03.951599 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.951601 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.954710 IP 162.125.64.14.443 > 192.168.0.1.54817: tcp 0 12:25:03.954791 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.954792 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.955164 IP 162.125.64.14.443 > 192.168.0.1.13692: tcp 0 12:25:03.955238 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.955240 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.955393 IP 162.125.64.14.443 > 192.168.0.1.64306: tcp 0 12:25:03.955455 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.955456 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.958807 IP 162.125.64.14.443 > 192.168.0.1.54817: tcp 0 12:25:03.958809 IP 162.125.64.14.443 > 192.168.0.1.64306: tcp 0 12:25:03.958813 IP 162.125.64.14.443 > 192.168.0.1.13692: tcp 0 12:25:03.958881 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.958882 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.958886 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.958887 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.958919 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.958921 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.962223 IP 162.125.64.14.443 > 192.168.0.1.54817: tcp 0 12:25:03.962293 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.962294 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.962296 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.962446 IP 162.125.64.14.443 > 192.168.0.1.64306: tcp 0 12:25:03.962510 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.962512 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.962675 IP 162.125.64.14.443 > 192.168.0.1.13692: tcp 0 12:25:03.962741 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.962742 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.965638 IP 162.125.64.14.443 > 192.168.0.1.54817: tcp 0 12:25:03.965708 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.965710 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.966314 IP 162.125.64.14.443 > 192.168.0.1.64306: tcp 0 12:25:03.966381 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.966382 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.966542 IP 162.125.64.14.443 > 192.168.0.1.13692: tcp 0 12:25:03.966601 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.966603 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.969500 IP 162.125.64.14.443 > 192.168.0.1.54817: tcp 0 12:25:03.969573 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.969575 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.969957 IP 162.125.64.14.443 > 192.168.0.1.13692: tcp 0 12:25:03.970017 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.970019 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.970183 IP 162.125.64.14.443 > 192.168.0.1.64306: tcp 0 12:25:03.970242 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.970244 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.973371 IP 162.125.64.14.443 > 192.168.0.1.54817: tcp 0 12:25:03.973373 IP 162.125.64.14.443 > 192.168.0.1.64306: tcp 0 12:25:03.973446 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.973448 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.973450 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.973452 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.973597 IP 162.125.64.14.443 > 192.168.0.1.13692: tcp 0 12:25:03.973666 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.973668 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.976783 IP 162.125.64.14.443 > 192.168.0.1.54817: tcp 0 12:25:03.976853 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.976854 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.977238 IP 162.125.64.14.443 > 192.168.0.1.64306: tcp 0 12:25:03.977307 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.977309 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.977466 IP 162.125.64.14.443 > 192.168.0.1.13692: tcp 0 12:25:03.977531 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.977533 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.980424 IP 162.125.64.14.443 > 192.168.0.1.54817: tcp 0 12:25:03.980490 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.980492 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.980651 IP 162.125.64.14.443 > 192.168.0.1.64306: tcp 0 12:25:03.980716 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.980718 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.981563 IP 162.125.64.14.443 > 192.168.0.1.13692: tcp 0 12:25:03.981626 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.981628 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.984520 IP 162.125.64.14.443 > 192.168.0.1.54817: tcp 0 12:25:03.984590 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.984591 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.984746 IP 162.125.64.14.443 > 192.168.0.1.13692: tcp 0 12:25:03.984814 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.984815 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.984980 IP 162.125.64.14.443 > 192.168.0.1.64306: tcp 0 12:25:03.985044 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.985045 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.987934 IP 162.125.64.14.443 > 192.168.0.1.54817: tcp 0 12:25:03.988004 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.988006 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.988161 IP 162.125.64.14.443 > 192.168.0.1.13692: tcp 0 12:25:03.988227 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.988228 IP 192.168.0.1.13692 > 162.125.64.14.443: tcp 1428 12:25:03.988389 IP 162.125.64.14.443 > 192.168.0.1.64306: tcp 0 12:25:03.988460 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.988461 IP 192.168.0.1.64306 > 162.125.64.14.443: tcp 1428 12:25:03.991802 IP 162.125.64.14.443 > 192.168.0.1.54817: tcp 0 12:25:03.991894 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428 12:25:03.991895 IP 192.168.0.1.54817 > 162.125.64.14.443: tcp 1428
I can confirm I am NOT using VPN of any kind. I am however using IPS on PfSense in the way or "Snort". I did add my Plex server to the "Pass-list" which from what I can see means that traffic to that IP should be ignored.
That being said, after looking at my floating rules I can see that traffic is being blocked related to Plex as per below :
-
@panzerscope when you do you packet capture, limit it to port 32400.. Or you just going to see ll your traffic flowing through the wan, and default settings is only 100 packets.. So by time you actually run the test, it may no longer if be even logging traffic.
Why have to weed through bunch of stuff you not interested in - just set the port to 32400 in the packet capture.
What about your states column?... Your floating are all 0/0 which means they have never even been evaluated..
I can confirm I am NOT using VPN of any kind
You sure - see that wireguard interface..
192.168.0.1
Where are you sniffing - sure looks like your wan is rfc1918.. So your pfsense is behind something doing nat.. Then nothing inbound would work, unless you setup port forward in what is in front of pfsense.. If you go to status interfaces, what is the IP on your wan?
If its 100.64-127.0.0 or 192.168.x.x, or 172.16-31.x.x or 10.x.x.x then your behind a NAT on pfsense wan, and no unsolicited inbound traffic would ever reach pfsense unless you forward that traffic where its being natted in front of pfsense.
-
@panzerscope when you do you packet capture, limit it to port 32400.. Or you just going to see ll your traffic flowing through the wan, and default settings is only 100 packets.. So by time you actually run the test, it may no longer if be even logging traffic.
Why have to weed through bunch of stuff you not interested in - just set the port to 32400 in the packet capture.
What about your states column?... Your floating are all 0/0 which means they have never even been evaluated..
I can confirm I am NOT using VPN of any kind
You sure - see that wireguard interface..
192.168.0.1
Where are you sniffing - sure looks like your wan is rfc1918.. So your pfsense is behind something doing nat.. Then nothing inbound would work, unless you setup port forward in what is in front of pfsense..
My bad. So I re-ran the port test while capturing only on port 3200 and the packet capture log is empty this time.
Wireguard is installed but not running, for the sake of removing it as a factor, I have removed this package.
For reference the packages I have installed are on the screenshot below:
So far as my WAN Interface, please see below:
-
@panzerscope Your behind a NAT, 192.168.0.1 is rfc1918 - it doesn't work on the internet.. There is no way for anyone on the internet to get to you..
Whatever your pfsense is plugged into, you need to set it up to forward 32400 to your plex wan IP 192.168.0.1
You stated
Yes I have a public IP right now
Clearly you do not..
-
@panzerscope Your behind a NAT, 192.168.0.1 is rfc1918 - it doesn't work on the internet.. There is no way for anyone on the internet to get to you..
Whatever your pfsense is plugged into, you need to set it up to forward 32400 to your plex wan IP 192.168.0.1
Ahh right ok. So on my ISP router (What Pfsense is plugged into), I need to setup a port forward on that device for 32400 -> 192.168.0.1 correct ?
-
@panzerscope Yup or put pfsense wan IP in the dmz host role so that all traffic is forward to pfsense... Or put that device in bridge mode, so it doesn't do nat, etc.
Impossible for pfsense to send anything to your plex, if it never sees the traffic because the device in front of pfsense is not sending it on to pfsense.