Caddy - pull trusted proxies from existing firewall alias, possibly?

[Patrick M. Hausen]

Hi all, but specifically Cedric (@monviech):

I just added Cloudflare's egress IP addresses to Caddy as trusted proxies in one of our installations so client IP addresses get passed properly down the chain. Works as designed. But feels a little clumsy:

- You can only select a single "Caddy access list" - I originally created two, one for IPv4, one for IPv6, because "of course" only to find I needed to combine them into one.
- Although Cloudflare last changed the lists in 2023 they provide them under a static URL in text CIDR format, so they could be trivially pulled into a firewall alias with the existing mechanisms.

I will happily create a feature request on Github, but wanted to discuss if that would be feasible, first.

Kind regards,
Patrick

[Monviech (Cedrik)]

Hello Patrick,

such a design has challenges.

We can define the alias as model relation field, and gather its contents.

But the issue is that aliases are a PF concept in which the data is not always the data that caddy might expect. That means we would have to sanitize or scope this very tightly.

The next issue is restarting caddy when the alias content changes during runtime. I'm sure there are hooks or possibilities for this somewhere, but it pollutes the isolated design.

By doing this, I will be forever responsible to ensure aliases are now going to be processed correctly, and my hand that feeds will be bitten by users who want more and more integration between aliases and caddy. (system wide alias usage is more of a core issue)

I usually only want to do this the other way around, an outside daemon populating a pf table (I do this in dnsmasq or ndp-proxy-go), not a pf table populating the configuration of a daemon that does not know the concept of a pf table.

I think this here is the same core issue:
https://github.com/opnsense/core/issues/9308

Using the API you could manage the access list of caddy externally though, since then you cannot skip the validation of the endpoint that ensures correctness:
https://docs.opnsense.org/development/api/plugins/caddy.html#id3

get_accesslist
set_accesslist et al...

[Patrick M. Hausen]

OK. How about being able to select more than one "Caddy internal access list" as a compromise? So one gets at least manageable objects for IPv4, IPv6, Cloudflare, other CDNs, ...

Also: what's with all the other fields in the access lists? Are any of them relevant for trusted proxies or just the address content?

[Monviech (Cedrik)]

What would be the best compromise is using something like this:

https://github.com/WeidiDeng/caddy-cloudflare-ip

But it's another module, though since I went the "I only support cloudflare in caddy" it looks attractive.

I also know who WeidiDeng is.

[Monviech (Cedrik)]

Selecting multiple access lists could also be thought about, I think I would have to merge the contents though and remove duplicates, but that's something that could be talked about.

Using the access list at that spot was not a good decision in hindsight, should have been a simple tokenized input field :D

[Patrick M. Hausen]

But it's another module, though since I went the "I only support cloudflare in caddy" it looks attractive.

I also know who WeidiDeng is.

Sounds awesome!

[Monviech (Cedrik)]

If this dynamic cloudflare IP approach is exactly what you need, feel free to open a github issue.

The footprint of this looks rather small.