Presenting different content based on origin of request

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?

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.

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

2 Likes

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

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

2 Likes

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?

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.

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
  }
}

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
}
1 Like

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

Freakin’ awesome :star_struck:

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.

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

1 Like

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