Caddy and Internal Access

Hello all,

I have a website that I made available using Caddy. It works from the outside, but when I am on the internal network it does not resolve.

1. The problem I’m having:

I am trying to access from my internal network. I have added the LAN rules to my firewall, but here is where its a little funky. I had to setup my website to talk on ports 8080 and 8443. I am using my Synology NAS to host this website. Caddy is configured to know that the internal website is on port 8080, and as I said it resolves fine from the outside.

2. Error messages and/or full log output:

The website never resolves internally. It says it took too long to resolve.

3. Caddy version:

I am running version 1.5.6 on my OPNsense firewall

4. How I installed and ran Caddy:

I installed via the provided tutorial: Caddy: Reverse Proxy — OPNsense documentation

a. System environment:

Website is running on a Synology NAS, with DSM 7.2, and Apache 2.4.

What do you mean by “resolves”? Show an example request with curl -v, show your Caddy logs. We need to see the actual error you’re getting.

1 Like

I mean when I enter into my browser, while on an internal network it does not show me the main page of the website. If you do the same on the outside it it does show me the main page of the website.

What syntax of curl do you want to see…

But what does “does not show me” mean? That could be an infinite amount of symptoms. What specifically happens? Does it just spin/hang and never load, or do you get an error message, or what? We need specifics. Different symptoms lead to different solutions. Just saying “it doesn’t work” is not useful at all for troubleshooting. (E.g. you don’t go to your doctor and just say “my body doesn’t work, help”, you tell them what’s not working specifically and the evidence you have)

Just run curl -v from inside your local network and show what you get.

1 Like

Here you go…

The curl command shows that nothing answers. Is the A-record pointing to the external IP address of the OPNsense? Did you create the necessary firewall rules as described here? (Please note you need them for all interfaces that need to connect, internal (e.g. LAN) and also external (e.g. WAN). Did you check that no old port forwarding rules are left?

Can you please also show your entire Caddyfile here? It’s important to fill out the whole help template.

1 Like

Yes there is an A record present…as mentioned external access works fine. Here is the caddyfile:
DO NOT EDIT THIS FILE – OPNsense auto-generated file

Global Options

log {
output net unixgram//var/caddy/var/run/log {
format json {
time_format rfc3339

grace_period 10s
import /usr/local/etc/caddy/caddy.d/*.global


Reverse Proxy Configuration

Reverse Proxy Domain: “4faae269-7eae-486a-a1d4-608d21fd9d31” {
handle {
reverse_proxy {

import /usr/local/etc/caddy/caddy.d/*.conf
Yes I did add the rules for each interface. Just to confirm, that even though Caddy uses 8080 to connect to my web server, that I should setup internal LAN interfaces to 80 and 443 correct?

Code blocks start with triple backticks ``` on their own lines before and after the config. You can use the </> button to help you with this. Your config as-is is unreadable because it’s not in code block formatting.

As @Monviech said, did you actually follow all the setup instructions for OPNsense? This is not a Caddy issue at this point, it’s a networking issue. If you were able to reach Caddy, then you wouldn’t be getting a timeout from curl, you’d see some other kind of error (possibly a TLS handshake error, HTTP error, etc)

1 Like

What is this trying to tell me??

2024-06-16T13:42:54-04:00 Debug caddy “debug”,“ts”:“2024-06-16T17:42:54Z”,“logger”:“http.auto_https”,“msg”:“adjusted config”,“tls”:{“automation”:{“policies”:[{“subjects”:[“”]},{}]}},“http”:{“grace_period”:10000000000,“servers”:{“remaining_auto_https_redirects”:{“listen”:[“:80”],“routes”:[{},{}],“logs”:{“logger_names”:{“”:“log0”},“should_log_credentials”:true}},“srv0”:{“listen”:[“:443”],“routes”:[{“handle”:[{“handler”:“subroute”,“routes”:[{“handle”:[{“handler”:“subroute”,“routes”:[{“handle”:[{“handler”:“reverse_proxy”,“upstreams”:[{“dial”:“”}]}]}]}]}]}],“terminal”:true}],“tls_connection_policies”:[{}],“automatic_https”:{},“logs”:{“logger_names”:{“”:“log0”},“should_log_credentials”:true}}}}}

It’s just a debug level log, showing that Caddy automatically adjusted its own config for Automatic HTTPS. Nothing to worry about.

Again, please mind your post’s formatting. Use triple backticks (not triple-quotes, backticks are the key to the left of the 1 on your keyboard, on US keyboard layouts anyway).

Please answer our questions. You’re making it very difficult for us to help you. It’s wasting time.

1 Like

Thanks for the help and pointing out the back tick key. Never would have found it…duhh!

I figured it out anyways…my domain name was the same as my internal name. It was causing a loop. I changed the config to be port based and its working inside/outside. On the inside I have to hit it by IP.

You mean you have created a reverse proxy loop? Curiously this has happened before just recently, but I can’t do much to validate for this configuration mishap.

Theoretically, I could input validate if the frontend and backend have the same value… But yeah.

1 Like

Yes it looks like it was a loop. I was working on a separate project and we were talking about a loop, so i went back and the internal name and it worked.

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