Remote acces : PiVPN, Tailscale or open port and a regular VPN ?

[Aenard]

Hello,

My current situation :
Running a Jellyfin server in a Debian 12 Virtual Machine on my ISP Internet box (Freebox Ultra, for my french fellows), to which I connect an external 4To drive through USB 3.0 for medias.
Local works wonderfully, have access through web browser on my computer and on my Amazon Firestick.

Now I'm trying to set-it up for remote access but I'm not sure which path to follow and to be fair I'm a bit confused.

1. First I've heard about reverse proxys it seems a bit obscure to me and from some comments not the best way any more.
   
2. Then I've found out about PiVPN.
   
3. Finally, the latest threads I found on reddit talked about the "easiest" way : Tailscale.
   

A few questions now :

1. Aren't PiVPN and Tailscale basically doing the same thing, and if not what's the difference ? 
   
2. Does those two use an "already opened / safe / secure" port on my router or do I have to open one myself any way ? 
   
3. In any case, do I have to use Dynamic DNS and if "yes" could you explain why ?
   
4. If I do have to open a port myself for them, how is it any better than getting a static IP, opening a port, forwarding it to the VM and connecting to it through my regular VPN to hide traffic ? (Proton Premium through Wireguard, in this case).
   
5. If I do en-up having to open a port, never communicate my static IP to anyone and always connect to it through Proton, what are chances someone finding it and what can they do, in my case, locked in a VM ? Can they go further ?
   
6. How do I control and limit write access of my jellyfinserver ?
   
7. Kind of a side question, but anybody with experience can comment the process difficulty and performances loss in encrypting the media drive with Veracrypt and how does it work with Jellyfin ?
   

Thanks in advance for taking the time to read and any enlightening you can provide !

[TheDreadPirate]

1.  They do the same thing in different ways.  Most people here that use VPNs for remote access prefer Tailscale.

2.  Tailscale does NOT require you to open any ports on your router.  PiVPN does.

3.  If you use Tailscale you do NOT need to use a dynamic DNS.  With PiVPN you do.  OpenVPN (the underlying VPN application of PiVPN) does not make it easy to change the VPN address on the client side of things if your IP were to change.  Having a DDNS address addresses that issue.

4.  Since this only applies to PiVPN, OpenVPN can be configured to use either a username and password for access OR a pre-shared key (you should do pre-shared keys).  With pre-shared keys, a person that stumbles on your VPN will have a much harder time gaining access.  But, it is not better than tunneling to your, I'm assuming, VPS with Wireguard.

5.  There are people scanning the Internet all.  The.  Time.  You should be less concerned about people finding your server and more about whether they can get in.  Because, I guarantee you, someone is port scanning your IP right now.  Keep in mind these are usually low effort script kiddies looking for Windows XP machines.  We are not worth the effort of hacking by actual skilled hackers.  As long as you keep your OS and apps up-to-date no one is getting in.

6.  There are a couple ways.  If you're using docker, you can specify that your media directories are read only.  Thats a concrete way of limiting write access to your media.  In Jellyfin, Dashboard > Users, there is a setting per use whether they can delete media or not.  If you aren't using docker, you can change the permissions on your media files so that the jellyfin user only has read permissions.

   

[bitmap]

On your insights:

1. Reverse proxy is the easiest for any end users. You set up the RP to proxy traffic from a domain or subdomain to your Jellyfin instance. With many tools that integrate certbot and auto-renewals, it's *relatively* easy to set up and the most secure way to make your instance publicly available. If you have many users or a large variety of clients, RP is definitely the way to go. More investment up front to learn, implement, and test, but easier for end users (nothing to install, one single address for JF instance).
...
3. This is misleading. Tailscale is a very secure way to allow access to your JF instance (or even your local network if you configure it that way). However, you have to install the Tailscale client on each device accessing the JF instance remotely. Easy for devices like phones or computers, harder for any OTT-type device (e.g., Roku, Firestick, etc...). Easy setup, more difficult for end users.

On your questions:

1. Yes. Tailscale is a specific implementation of Wireguard. PiVPN allows you to setup OpenVPN or Wireguard nodes to use in a similar fashion. Between the two, it may be easier to use Tailscale, though if you have a good understanding of networking, you can likely make either work.
2. You generally need to open a port for a VPN to exit, but I haven't used PiVPN or Tailscale. I have set up a Wireguard node and it requires a forwarded port to function properly.
3. I don't believe Tailscale requires any dynamic DNS config. In fact, neither really does, though you may need an IP updater for setting up your own Wireguard/OpenVPN instance. Reverse proxy would require DDNS to ensure your A record points to the correct IP address if you do not receive a static IP from your ISP.
4. Opening ports always carries a risk. When you have a service tied to a port (e.g., Wireguard node), that service becomes the entry point because it is assigned to the port. What you've described is completely opening a port on your server, which is the least secure route to go. You have encrypted the traffic with your VPN, but the port of entry on the server is still just wide open. Tailscale and Wireguard/OpenVPN (PiVPN) may require a port forward, but all traffic needs to go through a node on each end with permission to talk to the other. With a RP, all traffic from a single open port is routed to any of the services you have running and encrypted en route.
5. You're not a high-value target. Chances are low that you suffer an attack, but straight opening a port increases that risk substantially. Using your VPN doesn't matter -- script kiddies often scan for open ports on IP addresses via brute force. Using your commercial VPN makes no difference in the case where a malicious attacker finds the open port and has the ability to exploit any vulnerabilities present. What they can do depends on skill level and what security vulnerabilities exist. A VM isolates host access, but they can still wreak havoc within the VM if they're able to gain access.
6. Via credentials -- do not allow login/access without credentials -- and secure connections. Set strong passwords and hide usernames on the login page -- the less info you provide to somebody who may gain access, the better (i.e., security through obfuscation). You've named three solutions for remote access: open a port (VPN here is irrelevant for server security), run Tailscale or another OpenVPN/Wireguard solution (e.g., PiVPN), and full reverse proxy. Either of the latter two are much more secure than just opening a port.
7. I don't have an answer from experience with Jellyfin here, but there is a performance hit to encrypting drives. You use more CPU cycles and files cannot be accessed as quickly/directly. You're also not increasing the security of your system...if you open a port that provides open access to your server but you encrypt your media, all you're doing is punishing yourself. If somebody gains the right access, they could just re-encrypt your encrypted files and you've lost everything anyway. Local encryption is mainly for privacy, but given a good set of security measures in front of it (i.e., strong passwords, hidden usernames, Tailscale/OVPN/Wireguard or reverse proxy), that encryption means an attacker can't access the data directly, but they can still cause problems as previously described.

In other words:

A. Open port --> no real security
B. Tailscale/PiVPN/etc --> tunelled security, harder for end users in many cases
C. Reverse proxy --> encrypted traffic on public internet, easier for end users in most cases

[mildlyjelly]

This doesn't answer your questions directly, but I think it should clear up some things for you.

But first, you should always have an offline backup of any data that is important to you. There are plenty of ways for your data to be destroyed without the server being hacked. If you can, get a second external drive and backup anything important to it. Even better, use a third backup and keep it off site.

Basically there are 4 ways to remotely access your JF Sever.
1) Open a port directly to your server allowing you to simply navigate to the IP of your house. This only requires you to open a port in your router/firewall to direct traffic to your JF sever.

• Easiest to setup.
  
• It is very easy for end users to access via the JF app or Web Browser.
  
• Requires no special software.
  
• All data to and from your house is optionally securely encrypted.
  
• Provides the fastest connection.
  
• Least secure method (this doesn't mean dangerous, but you are relying entirely on your server and JF for security).
  
• Since your house IP can change without notice, this is where you would either want a static IP or a Dynamic DNS.
  
• There is really no way to enhance the security of this setup without using a Reverse Proxy (see method 4 below).
  

2) Use a VPN to connect to your house and then access your JF just like you would locally. This requires you to setup a VPN server on your router/firewall (or you can use PiVPN). You will also need a VPN client on remote devices (e.g. your phone) so you can connect to the VPN server. Once you have connected to the VPN server, you can securely access JF exactly as if you were on your local network (using the same local IP address as you do now).

• A very secure and traditional setup.
  
• Fairly easy to setup.
  
• All data to and from your house is securely encrypted.
  
• Allowing other people on your network comes with it's own security concerns.
  
• Provides a slower connection than Option 1, but depending on the hardware your VPN server is running on there may be no perceivable difference in speed or it my be horribly slow.
  
• Requires every end user to setup a VPN client and connect to your local internet before accessing your JF server.
  
• VPN client's are probably not available for most streaming devices like the Firestick, Roku, or AppleTV.
  
• You will still want to use a static IP or a Dynamic DNS since you will need to connect to your houses IP through the VPN.
  

Note: The VPN used in this setup is not like the one provided by Proton (and others like Tunnel Bear and NordVPN). Services like Proton's VPN are designed to hide you when you leave your house. It's like driving from your house to a Proton parking garage, then stealthfully exchanging cars before going to your destination. You still have to switch back to your regular car before you go home, and it doesn't prevent anyone from showing up at your house in any other car. The kind of VPN used here, to connect to your local network, is like a security gate at the end of your driveway, only people with the correct pass code are able to open the gate to get in.

3) Use Tailscale (I don't have personal experience with Tailscale)

• Probably more secure than using a VPN.
  
• Probably the second easiest to setup.
  
• All data to and from your house is securely encrypted.
  
• Requires every end user to install and use the Tailscale client before accessing your JF server.
  
• The Tailscale client's are probably not available for most streaming devices like the Firestick, Roku, or AppleTV.
  
• I'm not sure how well this works if you just want to give your friend temporary access for a few days.
  

4) Use a reverse proxy in front of option 1. For this to work, you will still need to open a port to your server exactly as you would have done in option 1. The big difference here is that we can limit access to your JF server to only the reverse proxy which has it's own unique benefits. You can set this up manually using Nginx or Apache on a remote server somewhere (not easy), or you can use a third party proxy provider like Cloudflare.

• Depending on how you implement the reverse proxy, this could be easy or difficult to setup.
  
• Likely more secure than Option 1 but still less secure than Options 2 & 3. You are now relying on your reverse proxy's server and JF for security. You get more security controls using a reverse proxy (i.e. WAF), but your proxy server and JF are still open to the pubic and can still be compromised. However, third party proxy providers like Cloudflare guarantee the security of their servers.
  
• It is very easy for end users to access via the JF app or Web Browser without special software.
  
• All data to and from your proxy is securely encrypted.
  
• You will still want to use a static IP or a Dynamic DNS since your reverse proxy will still need to connect to your houses IP.
  

[Aenard]

Ok so first of all I want to thank everybody for the thorough answers !
Didn't expect that much details but boy did you guys deliver...

It's made everything much clearer and helped me decide on a route.
As it seemed to be the "almost easiest" path but still secure and it fitted my end users (iOs / Android), I went for Tailscale and it went like a breeze. Easy install and setup, works like a charm and didn't have to dig deep with a terminal :-)

More important I think it helped me get a better better understanding of it all and I hope it will help others just as much.
Could be worth pinning somewhere as, from a noob perspective, looking for info on the topic on the web brings a tone of info, mixed, dated and frankly unclear.
Here at least the summaries makes it all readable.

Thanks you very much