Example: TP-Link Omada Controller

I spent some time today building a Caddyfile example for TP-Link Omada Controller software. Decided to share (and so fellow Googlers might save themselves some headaches going forward).


(snippet) {
        header {
                Strict-Transport-Security "max-age=31536000; includeSubdomains"
                X-XSS-Protection "1; mode=block"
                X-Frame-Options "DENY"
        tls me@email.com {
                dns cloudflare {env.CLOUDFLARE_API_TOKEN}
        log {
                output file /data/logs/caddy.log {
                        roll_size 20MiB
                        roll_keep 5

omada.url.com {
        reverse_proxy {
                transport http {
                header_up Host "omada.url.com:8043"
        import snippet

Few things to note:

  1. set to your Omada controller. Also check your controller’s HTTPS port - the default for docker is 8043, which is what I’m using, personally. To confirm - you should be able to navigate to (replacing with your values) and the controller should work great. If it doesn’t, this won’t work either.
  2. My snippet has some me-specific things that might not apply to you (Cloudflare DNS challenge, for example).
  3. You MUST use the header_up host header modification. It modifies the host header sent to the Omada controller to append the :8043 port. If this port isn’t in the host header, the Omada 302s the request to ensure HTTPs is being used (what a silly design, but whatever).
  4. An FYI - tls_insecure_skip_verify is inherently insecure. But since I trust the source, I’m not personally concerned. Ideally you would instead specify tls_trusted_ca_certs to trust the known certificate from the upstream. And the most ideal situation would be to add a valid cert to your Omada controller.

With this in place, my TPLink Omada Controller loads up great via Caddy!

1 Like