Server Version#:DS213j
Player Version#: 7.1.1
Why does the DSM keep trying to establish a port forward on my router to my Synology server? I don’t want anyone (including Plex) externally accessing my box. I keep manually disabling the access, and some process seems to be re-enabing it. Is there any way to permanently stop this process and simply prevent external entities having free will to access my server??
Now there is no remote access (Direct or otherwise) to your server.
When properly shutdown:
ChuckPa:
My Remote Access setting already looks identical to your screen print, but my Network Relay WAS enabled… so I disabled it. Hopefully this does the trick.
Do you have any idea why the default values here are to enable external access to the Plex Server? What’s the intended use for this? Targeted advertising maybe?
Thanks for your help.
Bill B.
To allow remote access to your media when your away from home.
There are those users who, unfortunately, don’t go looking into the server software and realize how much it can do.
There were many times when we would get “Please add feature X” where
the reply is “Feature X was implemented on (date). Please look here → blah blah”
After many of those, the product team, engineering team, and support team all concluded it was probably better to enable by default but be immediately ready to teach how to turn off any new feature which the user didn’t want.
So far the only forwards I’m allowing are for my SIP/IAX tele devices around the house. Unless I have a second vacation home (not yet) with a fixed IP so I can white list it through my home firewall… I think it’s too risky to allow open access port forwards onto my server. I’ll keep these port forwards disabled… until I score that juicy vacation home in the snowy hills of CO somewhere!
FYI.
You won’t need a static IP.
WireGuard site->site will automatically track DHCP changes on either end with a speed which makes IPSEC VPN look like dialup
Second point:
I use Pfsense firewall.
I define an AccessList (Alias) of those I allow.
I then defined a PASS rule to only allow Sources (members of that list) to reach my server.
I can give you my server IP and port here right now. To you, you won’t get any reply. I will be a whole in the internet to you.
It’s a given I wouldn’t be using IPSEC between 2 home locations behind fw whitelists…
The WireGuard option looks promising. So it’s fast? tricking things out using udp large blocks? Within the US between major ISPs that’ll probably work… otherwise, expect regular detritus during the stream…
Wireguard is extremely fast.
I have a WG tunnel to a friend in california. (I’m in Pa).
iperf3 between us varies maybe 1-2% but that may also be peering issues in transit
On a 20 Mbps (typical) iperf3. the variance in vs out is is a few KB/sec
Here’s the breakdown of wireguard header.
https://lists.zx2c4.com/pipermail/wireguard/2017-December/002201.html
Yeah… Pfsense is the Tops as far as firewall’s go. Is your setup inspecting MAC values of the inbound traffic? Mac values aren’t necessary for internet routing, so I don’t understand why they’re embedded in most (all?) packets… but that’s a topic for some other forum…
I don’t bother with MAC addresses because they are too easily spoofed.
Source FQDN (real FQDN or DDNS for DHCP users) or static addresses is what I allow
Yeah… UDP! Nothing here about additionally using “big” (bigger than 1500) blocks… maybe I’m getting that confused with some other protocol, or it came up after this 2017 mention…
Once I get that vacation home in The Hills… then I’ll start looking into DDNS for DHCP.
Thanks for this good idea!
If you incorrectly boost MTU, you’ll fragment somewhere along the way which is NOT COOL.
Jumbo packets work IF AND ONLY IFF ALL HOPS ARE THE SAME.
Out of interest how do you do that for DDHCP clients? These are typically random and change.
Now we’re getting into IETF stuff… so… if I’m sending a packet (usually sized at 1500) with, say, 4500 instead… is each hop expected to respect and pass on this same size… or might one hop force the big packet back down to 3 (“standard”) 1500 sized packets? Hmmm…
These various available solutions typically have a small program running on your client box that’s periodically sending out a probe msg to a dedicated server that then replies back with the latest visible public IP you’re xmitting from…
You might expect it to respect your MTU but guess what — IT WILL NOT.
It’s going to send at its MTU
They run the IETF Ethernet standards for a reason – Max Efficiency with minimal latency.
They will penalize you if you try to upset it with a jumbo packet
Again, MTU > 1500 is ONLY USED on dedicated circuits or networks where ALL NODES are configured with the same MTU (or larger… switches are that exception – they can be larger on your LAN – but all hosts must be identical and that’s not going to happen with COTS devices)
