Cannot start Caddy via Docker

Help
43

You are right. After careful examination I figured out I had made a mistake. 172.17.0.2 is the Caddy port not 172.17.0.3 as I posted before. It looked like the Caddy log has shown progress …

2023-01-12 10:20:06 {"level":"info","ts":1673536806.8534052,"logger":"http","msg":"done waiting on internal rate limiter","identifiers":["dzung.duckdns.org"],"ca":"https://acme-v02.api.letsencrypt.org/directory","account":"zung102@yahoo.com"}
2023-01-12 10:20:07 {"level":"info","ts":1673536807.326608,"logger":"http.acme_client","msg":"trying to solve challenge","identifier":"dzung.duckdns.org","challenge_type":"http-01","ca":"https://acme-v02.api.letsencrypt.org/directory"}
2023-01-12 10:20:07 {"level":"info","ts":1673536807.514995,"logger":"http","msg":"served key authentication","identifier":"dzung.duckdns.org","challenge":"http-01","remote":"172.17.0.1:52456","distributed":false}
2023-01-12 10:20:07 {"level":"info","ts":1673536807.5359616,"logger":"http","msg":"served key authentication","identifier":"dzung.duckdns.org","challenge":"http-01","remote":"172.17.0.1:52462","distributed":false}
2023-01-12 10:20:07 {"level":"info","ts":1673536807.6092107,"logger":"http","msg":"served key authentication","identifier":"dzung.duckdns.org","challenge":"http-01","remote":"172.17.0.1:52476","distributed":false}
2023-01-12 10:20:07 {"level":"info","ts":1673536807.756863,"logger":"http.acme_client","msg":"authorization finalized","identifier":"dzung.duckdns.org","authz_status":"valid"}
2023-01-12 10:20:07 {"level":"info","ts":1673536807.7570345,"logger":"http.acme_client","msg":"validations succeeded; finalizing order","order":"https://acme-v02.api.letsencrypt.org/acme/order/913730377/158401532297"}
2023-01-12 10:20:09 {"level":"info","ts":1673536809.0729744,"logger":"http.acme_client","msg":"successfully downloaded available certificate chains","count":2,"first_url":"https://acme-v02.api.letsencrypt.org/acme/cert/044dce3cde5335f44f520b6ff2a43a4763c2"}
2023-01-12 10:20:09 {"level":"info","ts":1673536809.079272,"logger":"tls.obtain","msg":"certificate obtained successfully","identifier":"dzung.duckdns.org"}
2023-01-12 10:20:09 {"level":"info","ts":1673536809.079442,"logger":"tls.obtain","msg":"releasing lock","identifier":"dzung.duckdns.org"}

However dzung.duckdns.org still timed out.

Can you see something still wrong here?

Vaultwarden is up and running fine. I can access it by this 192.168.0.146:8080

To me there is a conflict here. Port 443 is forwarded to Caddy. But https will use port 443 to reach Vaultwarden too?

Thank you very much for your help!

44

I can reach your Caddy server on port 80, but not on port 443.

$ curl --trace-ascii - https://dzung.duckdns.org/
== Info:   Trying 72.140.211.179:443...
== Info: Connected to dzung.duckdns.org (72.140.211.179) port 443 (#0)
== Info: ALPN, offering h2
== Info: ALPN, offering http/1.1
== Info:  CAfile: /etc/ssl/certs/ca-certificates.crt
== Info:  CApath: /etc/ssl/certs
== Info: TLSv1.0 (OUT), TLS header, Certificate Status (22):
=> Send SSL data, 5 bytes (0x5)
0000: .....
== Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
=> Send SSL data, 512 bytes (0x200)
0000: ......VG......b.6.}......_..d.1,~].... k,.4.Lkmy. Wk..D.mB..ta..
0040: |.Z.b...>.......,.0.........+./...$.(.k.#.'.g.....9.....3.....=.
0080: <.5./.....u.........dzung.duckdns.org...........................
00c0: .......3t.........h2.http/1.1.........1.....*.(.................
0100: ........................+........-.....3.&.$... -.....ck{1..z..
0140: ..Z...0}.......J................................................
0180: ................................................................
01c0: ................................................................
== Info: (5454) (IN), , Unknown (72):
<= Recv SSL data, 5 bytes (0x5)
0000: HTTP/
== Info: error:0A00010B:SSL routines::wrong version number
== Info: Closing connection 0
curl: (35) error:0A00010B:SSL routines::wrong version number

The clue here is that the received bytes start with HTTP/ which is not how a TLS connection handshake should start.

I think your port forwarding is messed up, routing 443 to 80 or something like that.

More evidence using telnet, I can see that connecting with port 443 does reach Caddy (since we see Server: Caddy) but it responds with HTTP which shouldn’t happen (under normal circumstances).

$ telnet dzung.duckdns.org 443
Trying 72.140.211.179...
Connected to dzung.duckdns.org.
Escape character is '^]'.
GET / HTTP/1.1
Host: dzung.duckdns.org

HTTP/1.1 308 Permanent Redirect
Connection: close
Location: https://dzung.duckdns.org/
Server: Caddy
Date: Thu, 12 Jan 2023 18:37:27 GMT
Content-Length: 0

Connection closed by foreign host.
45

I have tried the commands you used but got stuck below

zung@Dzungabc:/etc$ curl --trace-ascii - https://dzung.duckdns.org/
== Info:   Trying 72.140.211.179:443...
== Info: TCP_NODELAY set
^X^C
zung@Dzungabc:/etc$ telnet dzung.duckdns.org 443
Trying 72.140.211.179...
telnet: Unable to connect to remote host: Connection timed out

maybe because I was doing this from inside the router?

I was playing with the port forwarding scheme. It could be that you issued the commands at this time. Now I have set them as below and if you can detect anything wrong?
From router

HTTPS 443 ----> 443 for 192.168.0.146 (local IP)
HTTP 80 ----> 80 for 192.168.0.146

From Windows to Ubuntu and Caddy

Listen on ipv4: Connect to ipv4:

Address Port Address Port

192.168.0.146 80 172.17.0.2 80
192.168.0.146 443 172.17.0.2 443
192.168.0.146 8080 172.31.170.254 80

172.31.170.254 Ubuntu (or WSL) local port
172.17.0.2 Caddy Docker port

You can run the commands (curl, telnet) again to see if they work or not.
Thanks a lot.

46

Yeah it seems better now, but it seems like you have Caddy proxying either to itself or to another Caddy instance, which is also serving an HTTP->HTTPS redirect for requests over HTTPS, which causes infinite redirects.

$ curl -v https://dzung.duckdns.org/
*   Trying 72.140.211.179:443...
* Connected to dzung.duckdns.org (72.140.211.179) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=dzung.duckdns.org
*  start date: Jan 13 02:42:01 2023 GMT
*  expire date: Apr 13 02:42:00 2023 GMT
*  subjectAltName: host "dzung.duckdns.org" matched cert's "dzung.duckdns.org"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x55e57965de80)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: dzung.duckdns.org
> user-agent: curl/7.81.0
> accept: */*
> 
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 308 
< alt-svc: h3=":443"; ma=2592000
< date: Fri, 13 Jan 2023 04:07:14 GMT
< location: https://dzung.duckdns.org/
< server: Caddy
< server: Caddy
< content-length: 0
< 
* Connection #0 to host dzung.duckdns.org left intact

Yeah, your router probably doesn’t support NAT hairpinning, so you’re not able to connect to your WAN IP from inside of your network.

The usual way to resolve that is to run a DNS server inside your local network that can resolve your domain to your LAN IP instead for devices inside your network. If you have a pihole or adguard server, they could do this for you. Or maybe your router allows configuring domain overrides.

With curl you can override the DNS result with the --resolve flag, for testing:

curl -v --resolve dzung.duckdns.org:443:127.0.0.1 https://dzung.duckdns.org/
47

I only saw 1 instance of Caddy …

zung@Dzungabc:/etc$ docker ps
CONTAINER ID   IMAGE                       COMMAND                  CREATED          STATUS                  PORTS
                                       NAMES
d962ac5440c5   caddy:2                     "caddy run --config …"   55 minutes ago   Up 55 minutes           0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 443/udp, 2019/tcp   caddy
9f10be190f90   vaultwarden/server:latest   "/start.sh"              24 hours ago     Up 24 hours (healthy)   0.0.0.0:3012->3012/tcp, 0.0.0.0:8080->80/tcp                  vaultwarden

Would shutting down WSL and restart Caddy and Vaultwarden help?

48

What’s your Caddyfile at this point?

Your reverse_proxy might be proxying Caddy back to itself, instead of to vaultwarden.

49 
# encode gzip
 tls zung102@yahoo.com
# tls {
#    issuer acme {
#       disable_tlsalpn_challenge
#    }
# }
#  debug
# The negotiation endpoint is also proxied to Rocket
# reverse_proxy /notifications/hub/negotiate 0.0.0.0:80

# Notifications redirected to the websockets server
# reverse_proxy /notifications/hub 0.0.0.0:3012

# Send all other traffic to the regular Vaultwarden endpoint
#reverse_proxy 0.0.0.0:8008

reverse_proxy * 192.168.0.146:8080

}
50

If that’s the IP address of your server, then that won’t work. That’s the problem. You’re proxying Caddy back to itself, causing an infinite loop of redirects.

You need to proxy to the vaultwarden container.

51

which port should I use ?
reverse_proxy * vaultwarden:8080 or 80 ?

I started vaultwarden docker with -p 8080:80

52

Communication within the Docker network uses the internal port, i.e. 80.

You don’t need -p 8080:80 at all, you don’t need to publish the ports for vaultwarden to the host machine because the only thing that should be able to connect to it is Caddy.

I strongly recommend using Docker Compose, it’ll simplify managing your containers, and it’ll set up the Docker network for you automatically.

You can add your vaultwarden service to that example docker-compose.yml file.

53

I tried to set up the docker-compose.yml following the example here How to Install Vaultwarden with Docker on Ubuntu 22.04 - https://www.howtoforge.com/

The compose is as below …

version: '3'

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: always
    environment:
      WEBSOCKET_ENABLED: "true"  # Enable WebSocket notifications.
      DOMAIN: "https://dzung.duckdns.org"
      SMTP_HOST: "<smtp.domain.tld>"
      SMTP_FROM: "<vaultwarden@domain.tld>"
      SMTP_PORT: "587"
      SMTP_SECURITY: "starttls"
      SMTP_USERNAME: "<username>"
      SMTP_PASSWORD: "<password>"
    volumes:
      - ./vw-data:/data

  caddy:
    image: caddy:2
    container_name: caddy
    restart: always
    ports:
      - 80:80  # Needed for the ACME HTTP-01 challenge.
      - 443:443
   volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy-config:/config
      - ./caddy-data:/data
    environment:
      DOMAIN: "https://dzung.duckdns.org"  # Your domain.
      EMAIL: "zung102@yahoo.com"                 # The email address to use for ACME registration.
      LOG_FILE: "/data/access.log"

.... Caddyfile ...
dzung.duckdns.org:443 {
  tls zung102@yahoo.com
  reverse_proxy * vaultwarden:80

}
   Caddy port ...
       "Containers": {
            "a7b10429973a53eaf4fde986f47db72c64ccbbbb817c82f8e2bb9e38e0ccc6c9": {
                "Name": "caddy",
                "EndpointID": "342a037aa2a4c82fa19b9709d4f069aaeb20384595c26c681c833412cd78d86d",
                "MacAddress": "02:42:ac:17:00:03",
                "IPv4Address": "172.23.0.3/16",
                "IPv6Address": ""
            },
Forwarding set up ...
Address         Port        Address         Port
--------------- ----------  --------------- ----------
192.168.0.146   80          172.23.0.3      80
192.168.0.146   443         172.23.0.3      443

zung@Dzungabc:~/vaultwarden$ docker ps
CONTAINER ID   IMAGE                       COMMAND                  CREATED          STATUS                    PORTS
                                         NAMES
a7b10429973a   caddy:2                     "caddy run --config …"   10 minutes ago   Up 9 minutes              0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 443/udp, 2019/tcp   caddy
bd893ee9e444   vaultwarden/server:latest   "/start.sh"              10 minutes ago   Up 10 minutes (healthy)   80/tcp, 3012/tcp                                              vaultwarden

and the Caddy log …

2023-01-13 12:03:00 {"level":"warn","ts":1673629380.0986068,"msg":"Caddyfile input is not formatted; run the 'caddy fmt' command to fix inconsistencies","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":2}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.1009479,"logger":"admin","msg":"admin endpoint started","address":"localhost:2019","enforce_origin":false,"origins":["//127.0.0.1:2019","//localhost:2019","//[::1]:2019"]}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.1015737,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv0","https_port":443}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.1016626,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.1017184,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0001070a0"}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.1043591,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/data/caddy"}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.1056013,"logger":"tls","msg":"finished cleaning storage units"}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.1071653,"logger":"http","msg":"enabling HTTP/3 listener","addr":":443"}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.112495,"msg":"failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details."}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.120813,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.1211336,"logger":"http.log","msg":"server running","name":"remaining_auto_https_redirects","protocols":["h1","h2","h3"]}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.1211956,"logger":"http","msg":"enabling automatic TLS certificate management","domains":["dzung.duckdns.org"]}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.1232693,"msg":"autosaved config (load with --resume flag)","file":"/config/caddy/autosave.json"}
2023-01-13 12:03:00 {"level":"info","ts":1673629380.123347,"msg":"serving initial configuration"}

Caddy appeared not getting certificate?

I did this …

zung@Dzungabc:~/vaultwarden$ curl -v --resolve dzung.duckdns.org:443:127.0.0.1 https://dzung.duckdns.org/
* Added dzung.duckdns.org:443:127.0.0.1 to DNS cache
* Hostname dzung.duckdns.org was found in DNS cache
*   Trying 127.0.0.1:443...
* TCP_NODELAY set
* Connected to dzung.duckdns.org (127.0.0.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=dzung.duckdns.org
*  start date: Jan 13 00:00:00 2023 GMT
*  expire date: Apr 13 23:59:59 2023 GMT
*  subjectAltName: host "dzung.duckdns.org" matched cert's "dzung.duckdns.org"
*  issuer: C=AT; O=ZeroSSL; CN=ZeroSSL ECC Domain Secure Site CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x56466e8f5620)
> GET / HTTP/2
> Host: dzung.duckdns.org
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
< HTTP/2 200
< alt-svc: h3=":443"; ma=2592000
< cache-control: public, max-age=600
< content-security-policy: default-src 'self'; base-uri 'self'; form-action 'self'; object-src 'self' blob:; script-src 'self'; style-src 'self' 'unsafe-inline'; child-src 'self' https://*.duosecurity.com https://*.duofederal.com; frame-src 'self' https://*.duosecurity.com https://*.duofederal.com; frame-ancestors 'self' chrome-extension://nngceckbapebfimnlniiiahkandclblb chrome-extension://jbkfoedolllekgbhcbcoahefnbanhhlh moz-extension://* ; img-src 'self' data: https://haveibeenpwned.com https://www.gravatar.com ; connect-src 'self' https://api.pwnedpasswords.com https://2fa.directory https://app.simplelogin.io/api/ https://app.anonaddy.com/api/ https://api.fastmail.com/ ;
< content-type: text/html; charset=utf-8
< date: Fri, 13 Jan 2023 17:18:31 GMT
< expires: Fri, 13 Jan 2023 17:28:31 GMT
< permissions-policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(), fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()
< referrer-policy: same-origin
< server: Caddy
< server: Rocket
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-xss-protection: 0
< content-length: 1240
<
<!doctype html><html class="theme_light"><head><meta charset="utf-8"/><meta name="viewport" content="width=1010"/><meta name="theme-color" content="#175DDC"/><title page-title>Vaultwarden Web Vault</title><link rel="apple-touch-icon" sizes="180x180" href="images/apple-touch-icon.png"/><link rel="icon" type="image/png" sizes="32x32" href="images/favicon-32x32.png"/><link rel="icon" type="image/png" sizes="16x16" href="images/favicon-16x16.png"/><link rel="mask-icon" href="images/safari-pinned-tab.svg" color="#175DDC"/><link rel="manifest" href="ca8f66ed7fccfcd0809f.json"/><script defer="defer" src="theme_head.5f24ba8d7aa944e6f52b.js"></script><link href="app/main.82096a4e78d5d3f7b01b.css" rel="stylesheet"></head><body class="layout_frontend"><app-root><div class="mt-5 d-flex justify-content-center"><div><img class="mb-4 logo logo-themed" alt="Bitwarden"/><p class="text-center"><i class="bwi bwi-spinner bwi-spin bwi-2x text-muted" title="Loading" aria-hidden="true"></i></p></div></div></app-root><script defer="* Connection #0 to host dzung.duckdns.org left intact
defer" src="app/polyfills.428c25638840333a09ee.js"></script><script defer="defer" src="app/vendor.7c30c6e2b5ba56506ea9.js"></script><script defer="defer" src="app/main.5f8690f5c03a207c390a.js"></script></body></html>

Not sure the meanings of it …

Can you curl/telnet to dzung.duckdns.org and if you see any issue?

Thanks a lot

54

Looks like it’s working now.

But your Caddyfile now no longer has the rest of the stuff needed for vaultwarden I think, i.e. the proxy to port 3012 for the websockets server. Make sure to add that back in.

55

Can you show me the parameters to achieve that ? in Docker-compose file ? or in Caddyfile ?

I added this to Caddyfile

The negotiation endpoint is also proxied to Rocket

reverse_proxy /notifications/hub/negotiate 0.0.0.0:80

Notifications redirected to the websockets server

reverse_proxy /notifications/hub 0.0.0.0:3012

but it still timed out.

56

Again – you cannot use 0.0.0.0 to proxy to another container. Use the container name.

57

same result with

dzung.duckdns.org:443 {
  tls zung102@yahoo.com
# The negotiation endpoint is also proxied to Rocket
  reverse_proxy /notifications/hub/negotiate vaultwarden:80
# Notifications redirected to the websockets server
  reverse_proxy /notifications/hub vaultwarden:3012
  reverse_proxy  vaultwarden:80

}```
58

Did you actually reload Caddy to make it use the new config?

To be clear, loading https://dzung.duckdns.org works perfectly for me, I see your vaultwarden app.

Are you trying to connect from inside your local network? Like I said earlier, that probably won’t work if your router doesn’t support NAT hairpinning.

59

hmmm… so I need to install DNS server inside my local network …

Is it the same as specifying DNS servers (like google DSN servers 8.8.8.8 8.8.4.4) in router?

60

Yeah, except you’d point to a DNS server at a LAN IP.

You could use https://coredns.io/ which is quite easy to use, also written in Go.

Or you could use pihole or adguard which would have the side-benefit of blocking ads and such as well.

61

I was doing research on these DNS servers as suggested by you. I stumbled on some suggestion to use IPV6 to bypass the need for Nat Loopback. I specified my public IPV6 address at duckdns.org and it worked !!!

I have to thank you and thank gyfer very much for helping me to get Vaultwarden and Caddy to run successfully at the end.
Great help and great forum.

1 Like
62

This topic was automatically closed after 30 days. New replies are no longer allowed.