Caddy + Tailscale + Synology = Happiness

NetworkPrivacyWorkarounds

The discovery during looking to make Lighttpd run over TLS led me to find Caddy. It’s a TLS-first web server and reverse proxy that, frankly, is brilliant. It’s simple, works and is astounding.

The first use case was to move the Internet-based Pihole behind a TLS stack where nobody could sniff the extremely long and complicated UI password it has. In the Caddyfile (a JSON config file, almost as simple as can be), the DNS entry landing at Caddy is forwarded on the same host to port 1080.

pihole.mydomain.net {
        reverse_proxy localhost:1080
}

ifdyoxndutgspoikduufvaevpbdyanqmmmmoeakcuinbznqwtxpdgof.mydomain.net {
        reverse_proxy agentsmith.malk.ch:8000
}

tardis.mydomain.net {
        reverse_proxy 100.0.126.27:5000
}

delorean.mydomain.net {
        reverse_proxy 100.0.131.101:5000
}

int.pihole.mydomain.net {
        reverse_proxy 100.0.202.54:80
}

dmz.pihole.mydomain.net {
        reverse_proxy 100.0.15.76:80
}

dmz.nessus.mydomain.net {
        reverse_proxy 100.0.15.76:8834 {
                transport http {
                        tls_insecure_skip_verify
                        read_buffer 8192
                }
        }
}

int.nessus.mydomain.net {
        reverse_proxy 100.0.76.77:8834 {
                transport http {
                        tls_insecure_skip_verify
                        read_buffer 8192
                }
        }
}

Fine. Simple. Works. And scores great!

The key points are the green bars, A-rating and the SNI support; this means that the domains I have homed on this Caddy instance would have to be known before you can get to an application layer.

As is clear from the JSON Caddyfile above, there are four more sites being forwarded by this reverse proxy. The creativity I believe is high in how and what I have configured to be accessed via the proxy.

The Synology systems

There are two Synology systems accessible via the Caddy reverse proxy. The systems are behind two routers and the reverse proxy is forwarding the traffic over a Tailscale interface. Tailscale, massively rewarding.

The issue for a long time is that the Synology systems are not exposed to the Internet and thus TLS connectivity is annoying. ACME is not an option so the certificates are expired and modern browsers alert – or even block – traffic to the hosts. DuckDuckGo on iPadOS is extremely unforgiving!

As a compensating control, MFA is in place for the one account that can log into the DSM layer on those devices.

But there’s more. And more annoying.

Nessus Essentials

The Nessus boxes exist in my DMZ and internal network. Self-signed certificates also make the access annoying and so the reverse proxy on Caddy appealed.

The self-signed certificates also annoy Caddy so a little configuration is required in the Caddyfile.

domain.to.forward {
  reverse_proxy 100.x.x.x:8834 {
    transport http {
      tls_insecure_skip_verify
      read_buffer 8192
    }
  }
}

This configuration will accept connections on HTTPS for domain.to.forward and will then forward the traffic – ignoring TLS issues – to the Tailscale IP of the host. It will also work with a FQDN.

Naturally, the credentials should anyone arrive at the application layer are complex and completely random. Nessus Essentials appears to have no option for MFA but a single random username and password will be extremely difficult to guess.

Most excellently, all TLS certificate warnings are gone. Caddy is brilliant, compact and flexible. Consider this a recommendation.

Related Posts