How to use caddy to create a local LAN domain for a personal dashboard

Help
1

1. My Caddy version (caddy -version):

$ caddy --version Caddy v1.0.3 (h1:i9gRhBgvc5ifchwWtSe7pDpsdS9+Q0Rw9oYQmYUTw1w=)

2. How I run Caddy:

I use caddy with the hook.service plugin, the Caddyfile has hence been installed as:

caddy -service install -agree -email myemail@email.com -conf /path/to/Caddyfile

caddy -service start

a. System environment:

Raspberry Pi 3 B+ running Hypriot OS, caddy is installed directly in the host, no docker.

b. My complete Caddyfile:

$ cat caddy/Caddyfile
domain1.duckdns.org {
        proxy / https://192.168.1.66:444 {
                insecure_skip_verify
                websocket
                transparent
        }
}

domain2.duckdns.org {
        basicauth / admin Mo*Jg7CX!sP4
        proxy / 192.168.1.66:19999
}

dashboard.local {
        bind 192.168.1.66
        root /home/username/simple-dash
        tls self_signed
}

3. The problem I’m having:

In /home/username/simple-dash there is a simple dashboard which I’d like to make reachable only in my LAN (I don’t want to expose it to the internet) with a fancy and easy to type custom domain name.

4. Error messages and/or full log output:

When I type in my browser (Windows OS with latest Chrome browser) address bar dashboard.local a web search starts instead of loading my dashboard. I suppose either the Caddyfile is wrong (most likely) or some sort of “LAN domain broadcast” isn’t working.

5. What I already tried:

I gave a read to this and this.

2

Have you tried specifying https://dashboard.local so that your browser actually tries to connect to that instead of assuming you’re doing a web search?

In some quick testing, using dashboard.local on Chrome instantly assumes it’s a search, whereas Firefox does a DNS lookup for dashboard.local. Chrome seems to need that scheme to override its web search function.

3

I also happen to know that the TLD .local behaves strange on Ubuntu systems. Ubuntu has reserved .local for itself by default. Just my 0.2 here.
Also I bet it’s DNS.

2 Likes
4

I agree and somewhat made some steps forward. What I should have mentioned before is that I’m running PiHole on the raspberry (which also hosts Caddy).

So my network as of now is built as follow:

  • Fastgate (Fastweb) router is the DHCP server (and I don’t want to use PiHole as DHCP server)

    • I’ve discovered that the Fastgate uses the local TLD .lan and it can’t be changed (sadly it is a rather closed router)

  • Raspberry Pi with:

    • Caddy which is mainly working as a reverse proxy for several applications
    • PiHole which acts as a DNS server

Since my Fastgate router doesn’t allow to change the DNS server it forwards to clients I am manually setting my laptop DNS server to the Raspberry local IP, and so far everything works as expected, PiHole receives my laptop requests.

Following the instructions HOWTO: Using pi-hole as LAN DNS server I’ve added the DNS entry 192.168.1.66 61cygni.lan to PiHole (LAN IP of the Raspberry and the custom domain name I chose) and then I managed to “reach” the Raspberry at the address https://61cygni.lan/.

I am now getting this error:
421 Site 61cygni.lan is not served on this interface

The updated Caddyfile is:

61cygni.lan {
        bind 192.168.1.66
        root /home/maxiride/simple-dash
        tls self_signed
}

I’ve also had to specify https:// to avoid a google search to happen.

5

Is this:

Your entire Caddyfile, or are the other sites still present?

What’s the output from Caddy when it starts up with this configuration?

6 
$ sudo systemctl status caddy.service
â—Ź caddy.service - Caddy's service
   Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-10-24 08:57:10 UTC; 21s ago
 Main PID: 25941 (caddy)
    Tasks: 12 (limit: 2319)
   Memory: 4.0M
   CGroup: /system.slice/caddy.service
           └─25941 /usr/local/bin/caddy -agree=true -conf=/home/maxiride/caddy/Caddyfile -email=maxiride@gmail.com

Oct 24 08:57:10 61cygni caddy[25941]: Activating privacy features... done.
Oct 24 08:57:10 61cygni caddy[25941]: Serving HTTP on port 80
Oct 24 08:57:10 61cygni caddy[25941]: http://someurl.61cygni.duckdns.org
Oct 24 08:57:10 61cygni caddy[25941]: http://someurl2.61cygni.duckdns.org
Oct 24 08:57:10 61cygni caddy[25941]: Serving HTTPS on port 443
Oct 24 08:57:10 61cygni caddy[25941]: https://someurl.61cygni.duckdns.org
Oct 24 08:57:10 61cygni caddy[25941]: https://someurl2.61cygni.duckdns.org
Oct 24 08:57:10 61cygni caddy[25941]: Serving HTTP on port 2015
Oct 24 08:57:10 61cygni caddy[25941]: http://61cygni.lan:2015
Oct 24 08:57:10 61cygni caddy[25941]: WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with `ulimit -n 8
li

There are other websites served correctly.

$ cat caddy/Caddyfile
someurl.61cygni.duckdns.org {
        proxy / https://192.168.1.66:444 {
                insecure_skip_verify
                websocket
                transparent
        }
}

someurl2.61cygni.duckdns.org {
        basicauth / user pass
        proxy / 192.168.1.66:19999
}

61cygni.lan {
        bind 192.168.1.66
        root /home/maxiride/simple-dash
        tls off
}

I noticed by reading the caddy output the line http://61cygni.lan:2015, I somewhat thought that it would have been server on port 80 too but instead, a random port has been chosen (I’m totally fine with it in case). However I now get again a ERR_NAME_NOT_RESOLVED when loading http://61cygni.lan:2015.

I’m confident is some sort of local DNS issue and not a caddy one.

To try some sort of debugging I’ve added another entry to the Caddyfile:


:2016 {
        bind 192.168.1.66
        root /home/maxiride/simple-dash
        tls off
}

In the hope of reaching the dashboard using the address http://192.168.1.66:2016 but I ended up with ERR_CONNECTION_TIMED_OUT

7

I’d suspected. When you turn off Automatic HTTPS, Caddy reverts to default ports. In this case, port 2015. Also, previously it should’ve still been HTTPS, but it looks like you changed it to tls off since.

Annoying… This shouldn’t be dependent on the port. But, yeah, that’s a DNS problem.

Do you have a firewall on the host, and is it configured to pass port 2016 traffic?

8

No I don’t have any at the moment of this testing.

Seems that by adding a custom DNS entry into PiHole I managed to reach http://61cygni.lan:2015 so I’ll mark the topic as solved.

Nonetheless, this remain a mystery.

9

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