Reverse Proxy using Caddy (with optional automatic TLS)

[NasKar]

Good luck and enjoy the journey.

I think I'm getting close. Nextcloud is working but I'm getting this error in the GUI

Code:

The "Strict-Transport-Security" HTTP header is not set to at least "15552000" seconds. For enhanced security, it is recommended to enable HSTS as described in the security tips ↗.

Here is my Caddyfile

Code:

mydomain.cf {
root * /usr/local/www/html/
}
cloud.mydomain.cf {

  encode gzip
  reverse_proxy https://192.168.5.81 {
  }
}

collabora.mydomain.cf {
  # Static html, js, images, etc. served from loolwsd
  # Loleaflet is the client part of LibreOffice Online
  reverse_proxy loleaflet https://192.168.5.89:9980 {
 #   insecure_skip_verify
  }

  # WOPI discovery URL
  reverse_proxy hosting/discovery https://192.168.5.89:9980 {
  #  insecure_skip_verify
  }

  # Main websocket
  reverse_proxy lool https://192.168.5.89:9980 {
   # insecure_skip_verify
  }

  ## Admin console websocket
  #reverse_proxy lool/adminws https://192.168.5.89:9980 {
  #  insecure_skip_verify
  #  websocket
  #}

  # Show capabilities as json
    reverse_proxy hosting/capabilities https://192.168.5.89:9980 {
  #  insecure_skip_verify
  }
  # Download as, fullscreen presentation and image upload operations
  reverse_proxy lool https://192.168.5.89:9980 {
  #  insecure_skip_verify
  }
}

I had to add the root * instead of root
change 'proxy / http://.....' to 'reverse_proxy https://.....'
remove insecure_skip_verify and transparent

My collabora integration isn't working anymore. Will check your resource and check the steps.

 

[danb35]

Nextcloud is working but I'm getting this error in the GUI

So add that header in the relevant vhost block in the Caddyfile--see the examples in the Caddyfiles for the Nextcloud script.

 

[Basil Hendroff]

My collabora integration isn't working anymore. Will check your resource and check the steps

There's an updated Caddyfile code block for Collabora in the Nextcloud-Collabora resource.

 

[NasKar]

So add that header in the relevant vhost block in the Caddyfile--see the examples in the Caddyfiles for the Nextcloud script.

I finally got things working with the exception for the STS. Had to reboot my computer after making changes. Don't know why (probable the cache).
Here is my Caddyfile

Code:

{
#  acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
  email mydomain@gmail.com
}
mydomain.cf {
root * /usr/local/www/html/
file_server
header {
                 enable HSTS
                 Strict-Transport-Security max-age=31536000;
        }
}
cloud.mydomain.cf {

  encode gzip
  reverse_proxy http://192.168.5.81
}

collabora.mydomain.cf {
  encode gzip

  @collabora {
    path /loleaflet/*          # Loleaflet is the client part of LibreOffice Online
    path /hosting/discovery    # WOPI discovery URL
    path /hosting/capabilities # Show capabilities as json
    path /lool/*               # Main websocket, uploads/downloads, presentations
  }
  reverse_proxy @collabora http://192.168.5.89:9980
}

Can you add a reverse proxy for sonarr etc.. that would only be accessible from my local LAN and not the internet and keep the proxy for nextcloud? My index.html landing page is live on the internet and I don't want it to be.

 

[danb35]

Can you add a reverse proxy for sonarr etc.. that would only be accessible from my local LAN and not the internet and keep the proxy for nextcloud?

My answer to this is to use Caddy as an internal reverse proxy, and HAProxy on my OPNsense box for the things I want available from the Internet. I expect it could be done with a single Caddy instance, but I'd suggest you ask on the Caddy forum for more details. It looks like the remote_ip matcher would be relevant here.

 

[NasKar]

HAProxy on my OPNsense box for the things I want available from the Internet

That's on my list of future projects. Any idea why nextcloud still gives the Strict-Transport-Security error with

Code:

header {
                 enable HSTS
                 Strict-Transport-Security max-age=31536000;
        }

in my Caddyfile?

 

[danb35]

Any idea why nextcloud still gives the Strict-Transport-Security error with

Because you've only put that header in the main domain, not in the cloud. subdomain.

 

[Basil Hendroff]

Can you add a reverse proxy for sonarr etc.. that would only be accessible from my local LAN and not the internet and keep the proxy for nextcloud? My index.html landing page is live on the internet and I don't want it to be.

I've used a 'trick' to implement this. Like you, I have my landing page live on the internet. I have a Fritz!Box for my modem-router and have no experience with much more powerful tools like OPNsense or pfSense.

The trick takes advantage of the split-horizon DNS that is an integral part of the solution for the danb35's Caddy resource. As you will be aware, your public DNS and local DNS records for mydomain.cf differ. When you are on your LAN, a device will query mydomain.cf from your local DNS server and get the local IP address of your Caddy jail. When you are on the internet, a public DNS server responds to the same query with your external IP address. So for reverse proxies to resources that you only want accessible within your LAN, the trick is to turn off the public record of those resources. However, this trick only works if you've installed Caddy to perform a DNS challenge (DNS_CERT=1) rather than an HTTP challenge (STANDALONE_CERT=1).

For example, let's say you decide to set up a sonarr jail that you don't want accessible from the internet. Your local DNS server is already resolving mydomain.cf to your Caddy jail. Caddy will take care of resolving sonarr.mydomain.cf to your sonarr jail IP so you don't need to have a record in your local DNS server for sonarr. However, for HTTP validation to be successful, a CNAME record for sonarr is required. This automatically makes your sonarr jail publicly accessible via sonarr.mydomain.cf. On the other hand, no such record is required for DNS validation so, in that case, entering sonarr.mydomain.cf in your browser will throw up an error. Even if sonarr is listed on your landing page, it remains inaccessible from the internet. With DNS validation, only resources that you want to be accessible from the internet need to have a CNAME record. Looking at your present Caddyfile, this would include cloud.mydomain.cf and collabora.mydomain.cf.

Btw, I would encourage you to look at danb35's Heimdall resource for a very stylish landing page. It's brilliant, and dead easy to set up and configure!

 

[danb35]

Btw, I would encourage you to look at danb35's Heimdall resource for very stylish landing page.

Not quite ready for production with Caddy v2, though.

 

[NasKar]

However, this trick only works if you've installed Caddy to perform a DNS challenge (DNS_CERT=1) rather than an HTTP challenge (STANDALONE_CERT=1).

I'm using Freenom which Cloudflare doesn't support anymore for DNS challenge. So I have ports 80 & 443 directed to the caddy jail. Thanks for the detailed response.

 

[danb35]

I'm using Freenom which Cloudflare doesn't support anymore for DNS challenge.

More precisely, Cloudflare's free plan doesn't let you use their API to change DNS records for those TLDs. You could do it with a paid plan on Cloudflare, but it'd probably be cheaper to get a different domain. Or do what you're doing.

 

[Basil Hendroff]

Can you add a reverse proxy for sonarr etc.. that would only be accessible from my local LAN and not the internet and keep the proxy for nextcloud? My index.html landing page is live on the internet and I don't want it to be.

The good folk at the Caddy Community have made me aware of the remote_ip request matcher that will basically address this problem for you. It allows you to implement the following logic:

'If the request is from the internet, present a restricted landing page, otherwise (it's from your private network so), present an unrestricted landing page.'

Assuming your LAN address is 192.168.1.0/24 and you're serving static landing pages index.html (the default) to your LAN users and restricted.html to the internet, and both these files reside in /usr/local/www/html, the Caddyfile code block for mydomain.cf would be something like the following:

Code:

mydomain.cf {
  @untrusted not remote_ip 192.168.1.0/24

  root * /usr/local/www/html
  file_server @untrusted {
    index restricted.html
  }
  file_server
}

It works surprisingly well! For the full discourse on this, refer to this Caddy Community thread Presenting different content based on origin of request

 

[NasKar]

It works surprisingly well!

Wow, thanks for the follow up. I was looking into using HAProxy in my pfsense router but now I may not need to. Currently I'm in the process of restoring my backup to a new pool so I don't want to mess with my router. I did it in 2 steps everything but my media first and then my media as the second step. This allowed me to make sure it worked before making the large transfer.

Here is my Caddyfile

Code:

{
#  acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
  email mydomain@gmail.com
}
mydomain.cf {
@untrusted not remote_ip 192.168.5.0/24
root * /usr/local/www/html/
  file_server @untrusted {
    index restricted.html
  }
file_server
header {
                 enable HSTS
                 Strict-Transport-Security max-age=31536000;
        }
}
cloud.mydomain.cf {

  encode gzip
  reverse_proxy http://192.168.5.81
header {
                 enable HSTS
                 Strict-Transport-Security max-age=31536000;
        }
}

collabora.mydomain.cf {
  encode gzip

  @collabora {
    path /loleaflet/*          # Loleaflet is the client part of LibreOffice Online
    path /hosting/discovery    # WOPI discovery URL
    path /hosting/capabilities # Show capabilities as json
    path /lool/*               # Main websocket, uploads/downloads, presentations
  }
  reverse_proxy @collabora http://192.168.5.89:9980
}

I get "Failed to load Collabora Online Development Edition - please try again later" when trying to open a spreadsheet. I thought it was working after the replication but maybe not as reloading the previous caddyfile doesn't fix it.

 

[Basil Hendroff]

I get "Failed to load Collabora Online Development Edition - please try again later" when trying to open a spreadsheet. I thought it was working after the replication but maybe not as reloading the previous caddyfile doesn't fix it.

Did you validate your updated Caddyfile before running it service caddy validate? Your indentation is all over the place and it doesn't look right to me. I suggest you get the original Caddyfile working again before complicating matters further.

 

[NasKar]

It does validate.

Code:

service caddy validate
2020/08/16 19:14:13.885    INFO    using provided configuration    {"config_file": "/usr/local/www/Caddyfile", "config_adapter": "caddyfile"}
2020/08/16 15:14:13 [INFO][cache:0xc00003b4a0] Started certificate maintenance routine
2020/08/16 19:14:13.887    INFO    http    server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS    {"server_name": "srv0", "https_port": 443}
2020/08/16 19:14:13.887    INFO    http    enabling automatic HTTP->HTTPS redirects    {"server_name": "srv0"}
2020/08/16 15:14:13 [INFO][cache:0xc00003b4a0] Stopped certificate maintenance routine
Valid configuration

My caddy.log

Code:

{"level":"error","ts":1597604716.7012024,"logger":"http.log.error","msg":"dial tcp 192.168.5.89:9980: i/o timeout","request":{"method":"GET","uri":"/hosting/capabilities","proto":"HTTP/1.1","remote_addr":"192.168.5.81:63113","host":"collabora.mydomain.cf","headers":{"User-Agent":["Nextcloud Server Crawler"]},"tls":{"resumed":false,"version":771,"ciphersuite":49196,"proto":"http/1.1","proto_mutual":true,"server_name":"collabora.mydomain.cf"}},"duration":10.003832678,"status":502,"err_id":"2fb9xka4v","err_trace":"reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:411)"}

 

[NasKar]

It looks like the collabora VM didn't start. Can't get the OK with http://192.168.5.89:9980/ even after restarting the VM. May have to reboot but will have to wait till tomorrow when replication is finished.

 

[Basil Hendroff]

Do you have your original Caddyfile working? If not, please get that working first.

 

[NasKar]

yes I have the original Caddyfile working. After switching the new one I hit the rate limit. Will have to wait and hour and uncomment the staging line in the caddy file

 

[Basil Hendroff]

To anyone who uses this resource, I would like to draw your attention to this excellent, recent wiki article Using Caddy as a reverse proxy in a home network over at the Caddy community forum. It's an easy read and presents a good overview of the topic. Kudos to danb35 for developing this idea for the FreeNAS community over a year before this article saw the light of day.

 

[NasKar]

I get "Failed to load Collabora Online Development Edition - please try again later"

Everything works including both landing pages for LAN /WAN after reboot. Thanks Basil