It's also nice to be able to access your own services while travelling. The operation of a publicly accessible Gitea installed in the local network can be realised ingeniously simply with a Let's Encrypt certificate and HAProxy on the OPNsense firewall.
Nevertheless: This expansion stage is now suitable for public operation, but it has to be updated and maintained regularly now. Nothing is worse than an outdated and thus vulnerable installation.
Last updated:
This makes the setup look like this:
┌─────────────────────────────┐
│ TrueNAS / FreeBSD │
┌──────────────────────┐ │ ┌─────────────────────────┐ │
│ OPNsense │ │ │ jails/git │ │
WAN: 0.0.0.0:80 ─┼─► acme.sh:80 ───────┼─ LAN: 0.0.0.0:3000 ─┼─┼─► gitea │ │
WAN: 0.0.0.0:443 ─┼─► HAProxy:443 │ │ │ │ │
│ │ │ └─────────────────────────┘ │
└──────────────────────┘ └─────────────────────────────┘OPNsense is able to create and automatically renew Let's Encrypt certificates with the ACME client plugin (os-acme-client). The huge advantage is that we have a centralised certificate management system, do not need to laboriously manage the certificates on the internal target systems and do not have to make any NAT or other firewall settings.
The basic settings as described here with the following definitions are sufficient here:
HAProxy receives the calls for port 443 from the outside, encrypts the connection and forwards it to the internal Gitea server on port 3000. The nice thing is that here again the administration takes place centrally, the certificates can be used without any effort from Let's Encrypt and several services can be provided at the same time on port 443. The difference is made by the called external hostname. This makes it possible that e.g. https://git.domain.de is forwarded to Gitea and https://domain.de to the actual website, although both actually require port 443 on the same external IP address.
You can also go through this article here with the following definitions:
Then please test the following:
Voilá