Caddy on separate machine from router or services

Help
1

I have a VM running OpenSUSE behind my router that I use as a “jumpbox” that previously I’ve used to SSH into my network, so that only the SSH port is open. I’ve installed Caddy on that machine, as it seems appropriate for the use. It has two NICs, one has a routable address (192.168.X.X), the other address (10.X.X.X) has no gateway, therefore unroutable. My DNS for each VLAN ends in 253.

I’ve forwarded 80 and 443 to this VM. I’ve added a bind directive to try and keep Caddy off the 10.X.X.X interface.

When I fire up the Caddy service, I get this when checking status:

Sep 02 22:06:24 servicebox caddy[5146]: 2019/09/02 22:06:24 [INFO] [domain.tld] acme: Obtaining bundled SAN certificate
Sep 02 22:06:25 servicebox caddy[5146]: 2019/09/02 22:06:25 [INFO] [domain.tld] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/170279903
Sep 02 22:06:25 servicebox caddy[5146]: 2019/09/02 22:06:25 [INFO] [domain.tld] acme: Could not find solver for: tls-alpn-01
Sep 02 22:06:25 servicebox caddy[5146]: 2019/09/02 22:06:25 [INFO] [domain.tld] acme: Could not find solver for: http-01
Sep 02 22:06:25 servicebox caddy[5146]: 2019/09/02 22:06:25 [INFO] [domain.tld] acme: use dns-01 solver
Sep 02 22:06:25 servicebox caddy[5146]: 2019/09/02 22:06:25 [INFO] [domain.tld] acme: Preparing to solve DNS-01
Sep 02 22:06:35 servicebox caddy[5146]: 2019/09/02 22:06:35 [INFO] cloudflare: new record for domain.tld, ID b5fd492c6e7c0b47036f4377faae503c
Sep 02 22:06:35 servicebox caddy[5146]: 2019/09/02 22:06:35 [INFO] [domain.tld] acme: Trying to solve DNS-01
Sep 02 22:06:35 servicebox caddy[5146]: 2019/09/02 22:06:35 [INFO] [domain.tld] acme: Checking DNS record propagation using [192.168.X.253:53 10.X.X.253:53]
Sep 02 22:06:35 servicebox caddy[5146]: 2019/09/02 22:06:35 [INFO] Wait for propagation [timeout: 2m0s, interval: 2s]

Sep 02 21:54:06 servicebox caddy[4541]: 2019/09/02 21:54:06 [INFO] [domain.tld] acme: Waiting for DNS record propagation.
Sep 02 21:54:18 servicebox caddy[4541]: 2019/09/02 21:54:18 [INFO] [domain.tld] acme: Waiting for DNS record propagation.
Sep 02 21:54:20 servicebox caddy[4541]: 2019/09/02 21:54:20 [INFO] [domain.tld] acme: Cleaning DNS-01 challenge
Sep 02 21:54:21 servicebox caddy[4541]: 2019/09/02 21:54:21 [ERROR][domain.tld] failed to obtain certificate: acme: Error → One or more domains had a problem:
Sep 02 21:54:21 servicebox caddy[4541]: [domain.tld] time limit exceeded: last error: read udp 10.X.X.X:59715->10.X.X.253:53: i/o timeout
Sep 02 21:54:21 servicebox caddy[4541]: (attempt 3/3; challenge=dns-01)
Sep 02 21:54:22 servicebox caddy[4541]: 2019/09/02 21:54:22 failed to obtain certificate: acme: Error → One or more domains had a problem:
Sep 02 21:54:22 servicebox caddy[4541]: [domain.tld] time limit exceeded: last error: read udp 10.X.X.131:59715->10.X.X.253:53: i/o timeout
Sep 02 21:54:22 servicebox systemd[1]: caddy.service: Main process exited, code=exited, status=1/FAILURE
Sep 02 21:54:22 servicebox systemd[1]: caddy.service: Failed with result ‘exit-code’.

So it’s going to Cloudflare, authenticating successfully, but then I guess using my own internal DNS expecting the WAN IP to match? How do I keep Caddy from doing anything at all with the unnecessary interface?

Needless to say, the services I was hoping to have reverse-proxied are not available to the outside world.

Any insight would be appreciated.

2

Hi @jcdick1, welcome to the Caddy community.

Caddy’s ACME provider must check that the DNS provider has added the challenge record before it signals to LetsEncrypt to check for it and solve the challenge. Specifically, it is looking to make sure that the _acme-challenge. TXT record supplied by the ACME server is being returned by your namservers.

It’s not sufficient to signal the DNS provider and then immediately attempt the challenge. If the update is delayed at all - and DNS updates often are - we’d see huge numbers of challenge failures on a regular basis.

There’s no way to configure Caddy not to check for DNS propagation during a DNS challenge. Your options at the moment are to return to HTTP or TLS-ALPN challenges, or to ensure your local DNS server is resolving Caddy’s requests properly.

I note that the error appears to be a UDP timeout, indicating that your container’s request to your local DNS server is not receiving any response, so this might be a networking issue.

3

Yes, if I fire up Caddy, and also go into my dashboard on Cloudflare, I see the _acme-challenge. TXT item listed in the DNS on Cloudflare. But I have my local router/DNS sitting between Caddy and Cloudflare, resolving my local hostnames. How do I change the challenge method? Or should I go back to trying to understand how to get Caddy working directly on my router VM so that it is working directly with that WAN IP that Cloudflare has in its A and C records?

4

You have to have changed the challenge method to enable DNS validation - it’s not available by default, so just remove that.

In the context of the DNS challenge, where Caddy is running is not relevant (unless moving it should have an affect on the DNS resolution capabilities of the Caddy host). Also, it’s not necessary to run Caddy directly on your router if you forward the HTTP ports.

5

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