Trying to get Caddy to forward local subdomain to host:port

Help
1

I have set up Caddy in docker using the official image. I am using it to proxy my external subdomains (like ha.myhouse.net to 192.168.1.3:8123), and it is working as expected. All the certs get requested, and when I hit the subdomain, I get the proper app hosted locally.

My next thought was to get all of the servers on my internal network (*.home) to behave the same way. I want to be able to put in ha.myserver.home, and have it show me myserver.home:8123. What is happening is that I can ping ha.myserver.home, and I get the correct ip address back, but when I enter the url ha.myserver.home, I get:
404 Site ha.myserver.home is not served on this interface

There are no log entries from Caddy that I can see.

Here is a snippet of my Caddyfile:

        root /srv
    }

    ha.myserver.home {
        tls off
        proxy / 192.168.1.5:7080/admin {
          transparent
        }
    }

     www.externaldomain.com {
    proxy / http://192.168.1.30:8100 {
                insecure_skip_verify
                transparent
    }

Where do I need to look to figure out what is wrong?

Thanks,

K

2

Hi @Cad_Dy,

What does Caddy output when you launch it?

3

Here is the log from docker:

Activating privacy features... 
2019/01/29 00:54:40 [INFO][myserver.com] Obtain: Certificate already exists in storage
2019/01/29 00:54:40 [INFO][www.myserver.com] Obtain: Certificate already exists in storage
2019/01/29 00:54:40 [INFO][ha.myserver.com] Obtain: Certificate already exists in storage
done.
https://myserver.com
2019/01/29 00:54:41 https://myserver.com
https://www.myserver.com
2019/01/29 00:54:41 https://www.myserver.com
https://ha.myserver.com
2019/01/29 00:54:41 https://ha.myserver.com
http://myserver.com
2019/01/29 00:54:41 http://myserver.com
http://www.myserver.com
2019/01/29 00:54:41 http://www.myserver.com
http://ha.myserver.com
2019/01/29 00:54:41 http://ha.myserver.com

There is no mention of my localhost (ha.myserver.home) in the log .

4

Hmm! I was expecting to see a different problem entirely. Did you restart the container after making the Caddyfile changes, or did you send a USR1 signal to the Caddy process to reload it?

5

I restarted the container.

6

Huh.

What’s your docker run command / docker-compose.yml service for Caddy?

I’d assume that you’ve volume mounted the Caddyfile directly. I’m wondering if there’s some issue with the Caddyfile changes not being represented inside the container.

You could exec into the container and cat the Caddyfile that Caddy is using inside and just confirm that it does in fact show your ha.myserver.home block?

7

Here is my docker-compose.yaml

    image: abiosoft/caddy:no-stats
    container_name: Caddy
    restart: unless-stopped
    ports:
      - 80:80
      - 443:443
      - 2015:2015
    volumes:
      - ./Caddy/Caddyfile:/etc/Caddyfile
      - ./Caddy/srv:/srv
      - ./Caddy/LetsEncrypt_Certs:/etc/caddycerts
    environment:
      - TZ=America/Denver
      - CADDYPATH=/etc/caddycerts
      - ENABLE_TELEMETRY=false
      - ACME_AGREE=true
    labels:
      - com.centurylinklabs.watchtower.enable=True

The Caddyfile is mounted correctly. The contents are the same inside the container as outside the container. I even made a change externall, restarted the container, and verified that /etc/Caddyfile in the container reflected the changes I made.

I was hoping I had messed up the mount, no such luck!

8

Whoa, you can trigger Watchtower by labeling your services? When did that feature get in? That’s nice!

Well, we might need to take a closer look at the Caddyfile itself, then.

Can you post your entire Caddyfile?

9

I was just setting up Watchtower on a new server, and I saw that option. I don’t recall seeing a few months ago.

10

Yeah, just looked over the v2tec image. Seems like --label-enable is fairly new. The container itself was updated a year ago, though… so maybe it’s older than I thought!

11

Here is the entire Caddyfile. The only thing I did was remove passwords and change the server name.

myserver.com {
    root /srv
}

ha.zotac.home {
    tls off
    proxy / 192.168.1.5:8123 {
        transparent
    }
}

pihole.zotac.home {
    tls off
    proxy / 192.168.1.5:7080/admin {
      transparent
    }
}

nodered.zotac.home {
    tls off
    proxy / 192.168.1.5:1880
}

www.myserver.com {
    basicauth / "username" "password"
    root /srv/www
}

ha.myserver.com {
    proxy / 192.168.1.5:8123 {
        websocket
        transparent
    }
}

portainer.myserver.com {
    proxy / http://192.168.1.30:9000 {
        websocket
        insecure_skip_verify
		transparent
    }
}

heimdall.myserver.com {
    basicauth / "username" "password"
    proxy / https://192.168.1.30:8443 {
		insecure_skip_verify
        transparent
    }
}
    
unifi.myserver.com {
    proxy / https://192.168.1.3:8443 {
        websocket
		insecure_skip_verify
		transparent
    }
}
12

I think you might be missing a few lines from the top. Otherwise the first line in the Caddyfile would be root /srv and probably wouldn’t parse very well.

Assuming the first few lines are well formatted, though, I can’t see anything that would cause an issue at a glance through.

Two more questions: What’s the caddy -version, and have you tried using http://pihole.zotac.home and removing the tls off directive?

13

I wonder if the cert Obtain errors are fixed by this commit: Calling ObtainCert() should be no-op if certificate already obtained · caddyserver/certmagic@01ffe8b · GitHub

14

Sorry about that. I had the ``` on the same line as the start of the file, and it did not show. It is fixed now.

caddy -version shows:

Caddy 0.11.2 (unofficial)

Removing the tls off results in this in the log:

Activating privacy features... 2019/01/29 03:11:42 [INFO][myserver.com] Obtain: Certificate already exists in storage
2019/01/29 03:11:43 [INFO] [ha.zotac.home] acme: Obtaining bundled SAN certificate
2019/01/29 03:11:43 [ha.zotac.home] failed to obtain certificate: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:malformed :: Error creating new order :: Name does not end in a public suffix, url: 
exit status 1

Then the entries for ha.zotac.home repeat until I stop the container. It was this error that originally led me to adding the tls off to the config.

Thanks

15

It’s very important that you also add http:// to the start of the site label if you do this, i.e.: http://ha.zotac.home

1 Like
16

Thanks! That was the missing piece. Once I added the http:// to the tls off servers, it worked.

I did a curl http://ha.myserver.home, and I am now seeing what I expected.

Thanks again for your help.

K

17

No worries, glad we could find a workaround for you.

I’ll have to look into this bug further, though. Your site should have been there (although it should have been on port 2015, not port 80), but according to the output you posted, Caddy wasn’t hosting that site at all. In short - what you had should have worked (to some degree).

18

Funny enough, that thought crossed my mind, and I had tried using port 2015 instead of 80, just in case. What you proposed works on port 80, so it does all I need it to.

19

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.