Reverse Proxy using Caddy (with optional automatic TLS)

[rio236]

What's showing in /var/log/caddy.log?

Code:

2020/03/22 07:36:34 [INFO] Caddy version: v1.0.4
2020/03/22 07:36:34 /usr/local/www/Caddyfile:12 - Error during parsing: Unknown directive '...'

 

[rio236]

Thanks for pointing out where to check for errors.
I found that I needed to remove the

Code:

...

from Caddyfile.

Please advise how I can store the config/data on a different pool.

 

[mistermanko]

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
  }
}

Wonderful summery.
I'm doing baby steps towards achieving what - as it seems - others have done very easily, more or less.

I cannot access cloud.mydomain.com from outside. From inside works but it wont redirect to https automatically. Forcing TLS by typing https://cloud.mydomain.com is returning ERR_CONNECTION_REFUSED
https://mydomain.com works, returns "Hello world." (content of index.html) just fine.
caddy.log of the Caddy file is not showing anything interesting.

caddyfile inside caddy jail:

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.111.200/ {
                transparent
        }
}

EDIT:
I did not reach the rate limit on the cert for cloud.mydomain.com. That's what would have made sense because I'm fiddling around with let's encrypt the whole day. But no, that's not the issue it seems.

 

[Basil Hendroff]

Was Nextcloud installed with NO_CERT=1? I recall having problems with other settings.

 

[mistermanko]

yup, I re-checked the config.php and there is no TLS or https involved.

 

[Basil Hendroff]

What the first line of /usr/local/www/Caddyfile say in the Nextcloud jail, not the Caddy jail.

 

[mistermanko]

Code:

cloud.mydomain.com:80 192.168.111.200:80 {

As a side note, my own domain is a .de TLD, whenever I post mydomain.com it's just for example purpose.

 

[Basil Hendroff]

Code:

cloud.mydomain.de:80 192.168.111.200:80 {

There's your issue I think. cloud.mydomain.de.

 

[mistermanko]

There's your issue I think. cloud.mydomain.de.

Hmm, that would be pretty counter-intuitive as I was under the impression, the nextcloud jail is only talking via unsecured http with the caddy jail.
var/log/caddy in the nextcloud jail is spitting out some serious things now:

Code:

2020/03/25 19:46:56 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3563039725
2020/03/25 19:46:56 [ERROR][cloud.mydomain.com] failed to obtain certificate: acme: Error -> One or more domains had a problem:
[cloud.mydomain.com] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for cloud.mydomain.com - check that a DNS record exists for this domain, url: (attemp>
2020/03/25 19:46:57 [INFO] [cloud.mydomain.com] acme: Obtaining bundled SAN certificate
2020/03/25 19:46:57 [INFO] [cloud.mydomain.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3563040055
2020/03/25 19:46:57 [INFO] [cloud.mydomain.com] acme: Could not find solver for: tls-alpn-01
2020/03/25 19:46:57 [INFO] [cloud.mydomain.com] acme: use http-01 solver
2020/03/25 19:46:57 [INFO] [cloud.mydomain.com] acme: Trying to solve HTTP-01
2020/03/25 19:46:59 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3563040055
2020/03/25 19:46:59 [INFO] Unable to deactivate the authorization: https://acme-v02.api.letsencrypt.org/acme/authz-v3/3563040055
2020/03/25 19:46:59 [ERROR][cloud.mydomain.com] failed to obtain certificate: acme: Error -> One or more domains had a problem:
[cloud.mydomain.com] acme: error: 400 :: urn:ietf:params:acme:error:dns :: DNS problem: NXDOMAIN looking up A for cloud.mydomain.com - check that a DNS record exists for this domain, url: (attemp>
2020/03/25 19:47:00 [INFO] [cloud.mydomain.com] acme: Obtaining bundled SAN certificate
2020/03/25 19:47:00 [ERROR][cloud.mydomain.com] failed to obtain certificate: acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:rateLi>
2020/03/25 19:47:01 failed to obtain certificate: acme: error: 429 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:rateLimited :: Error creating new>

Oh and I forgot to add https://cloud.mydomain.com is not available.

 

[Basil Hendroff]

I might be wrong, but just noting then there's a mismatch between the cloud domain names between the two Caddys. I'm just not sure at this stage how significant this is?

Do you have a CNAME record for cloud with your DNS hosting provider?

 

[mistermanko]

Do you have a CNAME record for cloud with your DNS hosting provider?

I just set one. You've crossed that out in your guide on page 5. Didn't thought that it would be necessary.
So far no change when opening https://cloud.mydomain.com

 

[Basil Hendroff]

I just set one. You've crossed that out in your guide on page 5. Didn't thought that it would be necessary.
So far no change when opening https://cloud.mydomain.com

It will take some time to propagate (possibly an hour or so - I can't recall exactly). See post #91.

 

[Basil Hendroff]

As a side note, my own domain is a .de TLD, whenever I post mydomain.com it's just for example purpose

Just spotted this.

 

[mistermanko]

It will take some time to propagate (possibly an hour or so - I can't recall exactly). See post #91.

Well, what can I say @Basil Hendroff. Good bless you and your family! :D

After adding the cloud CNAME and flushing all dns caches, https://cloud.mydomain.com was available.
TLS is still not working over LAN, which means opening https://cloud.mydomain.com from inside my lan is getting me ERR_CONNECTION_REFUSED but I can live with that and post #91 explains it. See Tip #2

So now onto the next challenge: installing jitsi in a jail and point it to meet.mydomain.com...
Maybe tomorrow...it's been a long day.

Thanks again!

***

TIP #1:
If logging-in from outside your local network takes very long, your caddy proxy ip may have activated the nextcloud bruteforce safety feature, which will prevent too many request from the same ip.
Logically, nextcloud interprets the proxy ip as a bruteforce attack because it stays always the same and generates lots of requests in a short amount of time over one interface.

The solution lies in adding "trusted_proxies" and "forwardes_for_headers" to the

/usr/local/www/nextcloud/config/config.php

Code:

/**
* List of trusted proxy servers
*
* If you configure these also consider setting `forwarded_for_headers` which
* otherwise defaults to `HTTP_X_FORWARDED_FOR` (the `X-Forwarded-For` header).
*/
'trusted_proxies' => array('203.0.113.45', '198.51.100.128'),

/**
* Headers that should be trusted as client IP address in combination with
* `trusted_proxies`. If the HTTP header looks like 'X-Forwarded-For', then use
* 'HTTP_X_FORWARDED_FOR' here.
*
* If set incorrectly, a client can spoof their IP address as visible to
* Nextcloud, bypassing access controls and making logs useless!
*
* Defaults to 'HTTP_X_FORWARED_FOR' if unset
*/
'forwarded_for_headers' => array('HTTP_X_FORWARDED', 'HTTP_FORWARDED_FOR'),

Source: https://help.nextcloud.com/t/30-sec-to-wait-before-login-since-update-10-0/2599/10

***

TIP #2:
If you have a Pi-hole local dns-resolver in use, you may want edit the dnsmasq file.
[...]
This way multiple sub.domains can point to one local ip adress wihtin your network when using pihole or dnsmasq for dns resolution.
This is not required if your reverse proxy is setup correctly. Subdomains should be resolved by their respective DNS-service, in my case cloudflare. As Basil describes it in the next thread.

Source: https://old.reddit.com/r/pihole/comments/9m5l15/need_help_modifying_hosts_file_to_redirect_some/

 

[Basil Hendroff]

add your subdomains, one entry per line:

I don't believe this is necessary. I've not had to include lines in DNSMasq for the subdomains. My current understanding of how the Caddy resource works:

Cloudflare, through the CNAME record, handles the subdomains. It uses the A record to point mydomain.de to the IP address assigned to your network. The local DNS resolver does need to resolve mydomain.de to the Caddy jail IP. Caddy, through the Caddyfile then directs requests to sub.mydomain.de or mydomain.de/subdir to the relevant internal resource.

Note that a served resource may not handle TLS termination itself, but offloads it to Caddy. I believe this is why you can access that resource using http://jail_IP, or using sub.mydomain.de or mydomain.de/subdir depending on how Caddy has been configured, but https://jail_IP will fail. This is an expected result as Caddy is handling the TLS termination.

 

[mistermanko]

Another day, another question: is it possible to forward UDP traffic trough caddy to a jitsi server?

 

[danb35]

I wouldn't expect so, but that's probably a question for the Caddy forums.

 

[mistermanko]

I wouldn't expect so, but that's probably a question for the Caddy forums.

Apparently it is, though only with a semi-supported "net"-plugin. I maybe switch to nginx as a reverse proxy.

 

[Basil Hendroff]

The Caddyfile code block below works quite well for TrueCommand.

Code:

truecommand.mydomain.com {
  tls {
    dns cloudflare
  }
  gzip
  proxy / http://10.1.1.21:8080 {
        insecure_skip_verify
        transparent
        websocket
  }
}

There is one anomaly though. If I select 'Go to web Interface'...

I end up with a blank screen, which I can get past by selecting 'View NAS in new tab'.

It's a small price to pay to avoid having to remember the IP: port.

 

[KevDog]

@DanB Are you using Caddy v1 or Caddy v2. Caddy website just keeps saying caddy1 about to go away. Is there a difference?