Reverse Proxy using Caddy (with optional automatic TLS)

[Heracles]

Hi Blueether,

As a test, what is the answer when you connect your Nextcloud directly with HTTPS://10.1.1.55 ?
Do you have the same error message ? If you do, then the problem is clearly in the Nextcloud config. It may be the base URL of your cloud being /nextcloud, the need for a trusted name in Nextcloud's config.php that will match the name you use to call your proxy or similar.

Here, my Nextcloud is running from a Docker in a separate host, my reverse proxy is HAProxy and files are mapped from FreeNAS over NFS. My setup is pretty different but at the end, everything should go to the same variables.

 

[danb35]

https already setup on the nextcloud jail.

That seems like a good guess--you're trying to proxy to https://10.1.1.55, which is guaranteed to give you a certificate error. If you can use the hostname instead, that would avoid that problem. But I think there are other issues that come up when using Nextcloud behind a reverse proxy--this seems to address at least some:

Reddit - Dive into anything

www.reddit.com

 

[blueether]

@Heracles if I point the modem directly to 10.1.1.56 it returns https://cloud.******.net/login just fine with no errors.
if I use https://10.1.1.55 it will return an invalid cert as the cert is issued for the FQDN
@danb35 I'll dig into the nextcloud jail and see if I can change the configs...

 

[Heracles]

Hi again BlueEther,

First, double check your IP addresses... You are pointing to .55 and .56. Be sure you go to the right one...

Also, when you configure your NAT / Port Forwarding, remember that the client still used the DNS name to reach the server and that DNS name is in the HTTP headers. So to end up on the right TCP port is not the only thing you need to achieve here.

So double check your IPs, call your cloud server directly, without any proxy, from your local LAN, and confirm that it is working from there.

We will work it from the moment you can reach it correctly from LAN. Need to walk before trying to run...

Good luck,

 

[blueether]

an anoying extra complication is that my ISP has just turned on CGNAT this morning on my line, here's hoping that they will chuck a free static ipv4 (and /56 ipv6) my way for breaking my internets...

Update: Well cant complain at a free static IPv4 and /56 IPv6 I guess
Now on to fixing things...

 

[blueether]

After far too much trial and error and verious 503/404/tsl errors/cloud.******.net is not served on this interface/and around the block again I spotted two simple words in the caddy documentation: https://caddyserver.com/v1/docs/tls

Syntax
tls off
Disables TLS for the site. Not recommended unless you have a good reason. With TLS off, automatic HTTPS is also disabled, so the default port (2015) will not be changed.

The important peice of the puzle that I over looked [too many times as I skimmed the page] was "default port (2015)" as soon as I addedd :80 to the internal IP things started to work, then added back the cloud.*.net with :80 and things like magic just worked:

Caddyfile on the reverse proxy:

Code:

www.village*****.org.nz village*****.org.nz {
   gzip
   proxy / 10.1.1.56/ {
        transparent
   }
}

cloud.******.net {
   gzip
   proxy / 10.1.1.55/ {
        transparent
   }
}

www.bugger**.org.nz bugger**.org.nz {
   gzip
   proxy / 10.1.1.56/ {
        transparent
   }

caddyfile on nextcloud:

Code:

cloud.******.net:80 10.1.1.55:80 {
    root /usr/local/www/nextcloud
...
}

all in all I feel that this took me far to long to figure out

 

[ByteNick]

I need some help here, please...
I have a FreeNAS box with many jails in. One of them has nextcloud, another one caddy, to serve as reverse proxy for the entire setup.
my FQDN is example.com, with media.example.com/radarr, media.example.com/sonarr and some others working, but also with cloud.example.com, ombi.example.com and a couple of others on as well.

I am on cloudflare and everything works as supposed to, except for nextcloud. Can you please jelp me out?
- in nextcloud-config, do I go for STANDALONE_CERT=1 or for DNS_CERT=1 ?
- what would be the entry in CaddyFile for cloud.domain.com to work?
- 80 amd 443 ports should point internally towards the caddy jail, right?

Many anticipated thanks.

 

[danb35]

- in nextcloud-config, do I go for STANDALONE_CERT=1 or for DNS_CERT=1 ?

I'd use DNS_CERT.

- what would be the entry in CaddyFile for cloud.domain.com to work?

I have no personal experience with this, but the post immediately above yours appears to answer this question.

- 80 amd 443 ports should point internally towards the caddy jail, right?

Correct.

 

[Basil Hendroff]

Well after a couple of days of head-scratching and lots of trial and error, I've finally managed to get danb35's Nextcloud script and Reverse Proxy using Caddy resource to play nicely together. I may not be using the correct jargon below, but hopefully, you'll get my drift.

For the purpose of this explanation, Caddy will be installed in the jail at 192.168.1.10 and Nextcloud installed in the jail at 192.168.1.20.

A new Nextcloud installation is assumed. Caddy will be set up with DNS validation.

Note: If you have an existing Nexcloud installation installed via dan35b's script, Blueether's post above will give you a clue as to what may have to change on the Nextcloud Caddyfile. Adjust the steps below accordingly.

A broad outline of the steps:

1. If you haven't already done so, add a CNAME record for the subdomain cloud.mydomain.com. The record should point cloud to mydomain.com. This step is done using your DNS provider (I use Cloudflare).
2. Using dan35b's Nextcloud script, install Nextcloud at IP 192.168.1.20. Importantly, set HOST_NAME="cloud.mydomain.com" and NO_CERT=1 in the script configuration file nextcloud-config.
3. After installation, check that you can access the Nextcloud login page at http://192.168.1.20.
4. Forward ports 80 and 443 to the Caddy jail that will be located at 192.168.1.10 (I did this on my Fritz!Box modem router).
5. Install Caddy at jail IP 192.168.1.10 following danb35's resource Reverse Proxy using Caddy with the aim of setting up TLS with DNS validation.
6. Make sure you add mydomain.com to your DNS resolver (e.g. hosts file. I use DNSMasq) so that it resolves to 192.168.1.10 inside your network.
7. See below for how I set up Caddyfile so that https://mydomain.com reaches the Caddy landing page and https://cloud.mydomain.com reaches the Nextcloud login page.
8. Restart the Caddy jail and test that communication is encrypted for the domain names on the local network. If you need to debug your Caddyfile, var/log/caddy.log may provide some clues.

Code:

www.mydomain.com mydomain.com {
  tls {
        dns cloudflare
  }
  gzip
  root /usr/local/www/html/
}
cloud.mydomain.com {
  tls {
        dns cloudflare
  }
  gzip
  proxy / 192.168.1.20/ {
        transparent
  }
}

 

[Basil Hendroff]

@danb35 I think I'm beginning to better understand both the Caddy and Let's Encrypt resources that you have put together. They're designed to encrypt communications on the local network without certificate errors. They don't actually make any assertions about external access to those encrypted services. In fact, attempting to access those services externally causes say Cloudflare to throw up a 522 error.

I was under the mistaken impression that https is synonymous with the internet, which had me totally confused about these resources until you started to get me back on track in our discussion on the Let's Encrypt with FreeNAS 11.1 and later 0.3 discussion thread. I have updated the previous post accordingly.

Moving on from here, am I correct then in saying that if I were to execute step 4 in the previous post, it does mean that accessing www.mydomain.com from the internet brings me to the landing page of the Caddy jail, however, the Nextcloud login page (located at cloud.mydomain.com remains inaccessible until step 1 is also executed?

From our most recent discussion here, am I now correct in understanding that I will have more granular control over external access to nominated encrypted LAN services if I use the Caddy ipfilter plugin, but this may still require ports 80 and 443 to be open?

 

[danb35]

They're designed to encrypt communications on the local network without certificate errors. They don't actually make any assertions about external access to those encrypted services.

Correct. And in the case of the reverse proxy, also (maybe more so) to replace ip:8989 (etc.) with hostname/radarr, hostname/sonarr, etc.

Moving on from here, am I correct then in saying that if I were to execute step 4 in the previous post, it does mean that accessing www.mydomain.com from the internet brings me to the landing page of the Caddy jail, however, the Nextcloud login page (located at cloud.mydomain.com remains inaccessible until step 1 is also executed?

Also correct.

this may still require ports 80 and 443 to be open?

Not "may require", "will require."

 

[Basil Hendroff]

Tip: I've found it useful to keep the Caddyfile and index.html outside the jail. This simplifies recovery if the jail is hosed and then rebuilt e.g.

 

[danb35]

That sounds like a good tip, thanks.

 

[ByteNick]

@Basil Hendroff : Same should be also done for the logs.

 

[ByteNick]

Has anyone manages to put shinobi behind a proxy using Caddy?

It keeps asking me to same a gzip file each time I am accessing it. Not much on the internet regarding this except this post, but it does not work for me or, at least, I don't understand the instructions.

 

[Basil Hendroff]

Same should be also done for the logs.

@ByteNick Can you explain further please? I'm curious as to why you think so.

 

[ByteNick]

@ByteNick Can you explain further please? I'm curious as to why you think so.

All my apps config files and logs are stored in a samba shared folder that I can easily see (on a PC, for instance) without connecting through SSH. It is just for easiness. Nothing else.

 

[ByteNick]

Has anyone manages to put shinobi behind a proxy using Caddy?

It keeps asking me to same a gzip file each time I am accessing it. Not much on the internet regarding this except this post, but it does not work for me or, at least, I don't understand the instructions.

Not needed anymore. Problem solved.

 

[ByteNick]

The only jail not "solved" yet is the one containing calibre-web. I still cannot configure it yet behind caddy.

 

[Basil Hendroff]

Meanwhile, on topic, Caddy setup progress report:

1. As mydomain.com/app:
OK: emby, tautulli, radarr, sonar, lidarr, deluge, sabnzbd, nzbget.
NOK: plex-pass, transmission, headphones, calibre
Not tested: ombi, jackett

2. As sub.domain.com:
OK: ombi, urbackup, nextcloud, hass.io (home assistant)
NOK: duplicati
Not yet tested: Plex-pass,

On separate jail, I installed Orginizr v2, and the situation is NOT identical:
1. As mydomain.com/app:
OK: emby, tautulli, radarr, sonar, lidarr, deluge, sabnzbd, nzbget.
NOK: plex-pass, transmission, headphones, calibre
Not tested: ombi, jackett

2. As sub.domain.com:
OK: ombi, urbackup, nextcloud
NOK: duplicati
Not tested: Plex-pass, hass.io

Please note that nextcloud has been installed using your script, with STANDALONE_CERT set to 1

Useful reference. Did you ever get Plex-pass working with Caddy?