Presenting different content based on origin of request

[basil (Basil Hendroff)]

@matt

Because authentication is like a gate, if you let the reverse proxy (Caddy) do authentication too, you can better hide which service(s) you are running behind it. Otherwise if you let individual services do authentication, their login screens can obviously reveal that you are running that service. This might not be a problem for you; it just depends what you want.

I’m just wondering whether a way of hiding services would be to present a different landing for services based on the origin of the request. Is Caddy able to distinguish between a request originating from the router port forward and from within the LAN?

@matt

If, from within your own network, you cannot access your server, but you can from the outside, then it is likely your router does not support hairpin NAT (or does not have it enabled). I’ve encountered this problem with multiple ISP-provided routers and fixed it by running my own DNS server that resolves my public IP address to an internal address (and gives me redundancy against DNS provider outages too).

If not, I wonder if, through the split-DNS arrangement, whether requests from outside the network can be forwarded to one Caddy reverse proxy with a landing page with limited service offerings, while a second Caddy reverse proxy handles all internal requests? This second Caddy instance can have a landing page with a wider range of service offerings.

[francislavoie]

You can use the remote_ip matcher for this. For example requests from LAN might be matched with 192.168.0.0/16

Request matchers (Caddyfile) - Caddy Documentation

[basil (Basil Hendroff)]

Really?! I was just clutching at straws here! It’s possible?! AWESOME!!!

I’ll report my findings back shortly. Don’t go anywhere.

In case readers are wondering about the context, start here Using Caddy as a reverse proxy in a home network - #3 by matt

[basil (Basil Hendroff)]

The code block below assumes that static landing pages in /usr/local/www/html are being served. For the trusted network (10.1.1.0/24) the landing page will be index.html (the default). For the untrusted network (anything else!) the landing page will be untrusted.html.

mydomain.com {
  @trusted {
    remote_ip 10.1.1.0/24
  }
  @untrusted {
    not remote_ip 10.1.1.0/24
  }
  root * /usr/local/www/html
  file_server @trusted
  file_server @untrusted {
    index untrusted.html
  }
}

Can this be simplified any further?

[francislavoie]

That looks about right. You can reduce the matchers to a single line each by using the single-line matcher syntax (remove the { } and move the contents up to immediately beside the named matcher declaration.

You only need the “untrusted” matcher though, because the directives will be sorted with the most specific matcher first, so you can leave the opposite case as a fallback.

[basil (Basil Hendroff)]

I’m not so sure, or I’m just not understanding (probably the latter). I just tried this, and I got index.html for both the trusted and untrusted networks.

mydomain.com {
  @untrusted not remote_ip 10.1.1.0/24

  root * /usr/local/www/html
  file_server
  file server @untrusted {
    index untrusted.html
  }
}

[francislavoie]

@basil

file server

You’re missing a _ here!

Also I think there’s some weird behaviour going on with the Caddyfile directive sorting function that I’ll need to dig into more, but if you put the fallback file_server afterwards, it seems to adapt correctly, but not if you have it first. Caddy should always sort something that has any matcher before anything that has no matcher. I’ll do a bit of digging there.

Anyways, this should work for now:

mydomain.com {
  @untrusted not remote_ip 10.1.1.0/24

  root * /usr/local/www/html
  file_server @untrusted {
    index untrusted.html
  }
  file_server
}

[basil (Basil Hendroff)]

@francislavoie

You’re missing a _ here!

Oops. How did that happen? It was actually correct in my Caddyfile.

@francislavoie

Anyways, this should work for now:

mydomain.com {
  @untrusted not remote_ip 10.1.1.0/24

  root * /usr/local/www/html
  file_server @untrusted {
    index untrusted.html
  }
  file_server
}

Freakin’ awesome

Even if there is some weird behaviour, it costs an extra line and a bit to circumvent the issue. In some ways, the slightly longer version makes it clearer to a noob like me. I’m happy with both versions.

mydomain.com {
  @trusted remote_ip 10.1.1.0/24
  @untrusted not remote_ip 10.1.1.0/24

  root * /usr/local/www/html
  file_server @trusted
  file_server @untrusted {
    index untrusted.html
  }
}

I’m still curious as to what you find out about order issue e.g. a bug to be fixed, etc.

[francislavoie]

Yeah I consider it a bug. I just added a fix to the PR I already had open to fix another unrelated sorting issue (fix for this is case is in the 2nd commit):

https://github.com/caddyserver/caddy/pull/3658