====== Simple Approach: Remote Access ======

Accessing your home server from outside can be tricky. Please note that i am referring to accessing your **home server** from outside, **not** your home network. There is a big difference! 

=== Remote access to the server or to the network? ===

Access to the **home server** means access to your home services. You can, and should, remap using the reverse proxy any service which is not on the home server itself. 

Access to the **home network** means get an IP on the home network and behave like your device is plugged-in the home network. This is not desirable because it will expose the devices really on the internal network to additional risks: what if your mobile device, while outside, is compromised? You just opened an unsecured route to access home....

If you need access to the home network, and please think twice because 99% it is **not** what you really need, you should use wireguard instead of the following approach. 

=== External Reachability ===

You have a network interface of some kind between your home and your ISP provider. It could be a router or a gateway, it can be provided by the ISP or a device you bought and connected. This device acts as a firewall of kind and ensures that your home network is __not__ accessible from outside. 

In other words, unless you do specific actions, your home network will **not** be accessible from outside. Let's see what you could try.

=== Port Forwarding ===

If your ISP assign you a **real** IP address, then you can try to forward one or more ports so that those are reachable from outside. 

To achieve port forwarding, you need access to the network interface between your home and your ISP (your gateway, or modem, or router...) and the option must be available.

Anyway the hopes that this will work today are really slim, because:
  * Often ISPs will forbid it
  * Having a real IP today is really uncommon, CG-NAT is instead the new default.

=== CG-NAT ===

[[https://en.wikipedia.org/wiki/Carrier-grade_NAT|CG-NAT]], or Carrier-Grade NAT, is today the de-facto standard for residential internet access. In other words, today having a public IP is basically impossible, unless you are a lucky American (where IP4 address pools where generously granted in the past to ISPs) or willing to pay a lot of money for a specific service. And even in this case, it might not be available.

If you are behind CG-NAT, port forwarding is moot and you have only two options left:
  * Using a VPN service
  * Using an external server as bridge

In both cases, you need a **server** located externally to your home, and that can be reached from the internet, that you can use as an entry-point toward your home. The main difference is explained below.

=== Using a VPN ===

There are providers out there called VPN providers, that will let your home network be hidden behind a fake exit point. You pay (and __none__ will let you do this for free) and your home network connection toward the internet will be masked by the VPN exit node. Some of them will also let you do **port forwarding** (again, usually, for an extra price).

You will still have a dynamic IP address, and this solution also raise additional privacy concerns since now all your traffic goes trough a third provider which might not even be in your own country and obey different laws.

A VPN by itself, even with port-forwarding, is not yet enough, you still need a way to get back into the home server from outside.

__NOTE__: when talking about VPN, do not confuse this with Wireguard, which is still a VPN technically, but it's intended to work **on the other direction**, to get back inside.

=== External Server ===

Any server on the internet with an IP address can be used to access your home server. So why not rent one, even the cheapest VPS (Virtual Private Server), and make it your home access point away from home? 
The advantages over using a VPN are:
  * Usually cheaper (VPS can be rented for a fraction of the cost of a VPN)
  * More scalable: you can always upgrade when you want to a better / more expensive service
  * Can also be used as off-site backup storage if you purchase enough storage
  * You are in full control, you can even install your favorite OS yourself, given your VPS allows it.
  * The IP is static and will never change (with VPN, the exit node usually changes over time)

Some possible disadvantage:
  * One more server to install & manage beside the home server

Of course, if you have the means, go for a physical server which will guarantee you better privacy given that you will even rent the actual hardware. I do this, and it's about 20€ per month at the time of writing this page (2024).

=== The "getting back in" from outside part ===

Once you have established **how** you can make your home server visible on the internet, let's see how you can make so that you can access your services too. As i wrote at the beginning, the focus is on making your home services accessible, not your home network. This, again, is for security and protection. I assume all your services are already protected behind reverse-proxy, even at home, that provides an HTTPS encrypted layer and a common SSO authentication (more on this [[selfhost:nginx|here]] and [[selfhost:sso|here]]).

Unless you can have port-forwarding (but in this case you need to take care of Dynamic DNS for example), there are two ways to "get back in". Both are encrypted:
  * Using Wireguard: you setup a wireguard server at home, then you need to install and configure clients on all the devices connecting from outside
  * Using an SSH tunnel providing port-forwarding: this will allow __any__ device to access your services, and no specific setup on them.


===== Wireguard =====

TBD

===== SSH Tunneling =====

This is my preferred method, mostly because:
Advantages of SSH tunnels:
  * Easy to setup
  * Do not require any additional package on Linux (SSH is installed by default)
  * Works in any settings, always
  * Easily perform **all** kinds of port-forwarding natively and in both directions
  * Allows to expose public services and web pages
  * Allows access without any client configuration

Using SSH tunneling has one major drawback:
  * The real "client" IP is always replaced by **127.0.0.1** on the home server at low-level (so **not** a HTTP level), making tools like Fail-to-Ban of little use.

[[https://www.openssh.com/|OpenSSH]] is the default- SSH package installed in Gentoo. It creates a safe, encrypted tunnel between two hosts and it's based on [[https://www.openssl.org/|OpenSSL]]. OpenSSH supports many useful features for your use case:
  * Strong encryption of all exchanged data
  * Host identification based on public&private keys
  * User authentication based on public&private keys
  * Strong password-less authentication with 2FA (certificate + password)
  * Port forwarding from local to remote
  * Port forwarding from remote to local
  * TCP Keep-Alive support