Messages

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.

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

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.

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

See you in Brussels, possibly?

Right now I do not have any plans to go there. But if you ever want to meet in person, I am living close where you live :)

We only accept plugin contributions which glue around an existing freebsd port packages.

It's better to offer something like this in an own repository.

I don't mind this being here to be honest, a user who uses the shell as root should know what they are doing (hopefully). I know not all do know the implications, I also like to run simple install scripts on linux after all. I hope for the best xD

We're never safe from supply chain attacks as the current npm thingy shows once more (and did multiple times in the past but nobody is learning :O)

It will not come back that you can specify a range with two service aliases, also its a bit ambigous anyway.

A range http-https would mean all ports between 80-443, and not just exactly these two ports.

Better use a port alias with exact definitions.

Als Tangente ich bin extra von eigenem Modem auf Fritzbox zurück umgestiegen weil ich zu viele Probleme mit Providersupport im Fehlerfall hatte. Mit einem üblichem Endgerät als Terminierung hat man es grundsätzlich leichter.

I guess most of these issues are self inflicted due to the medium of internet.

If everybody would meet up on occasion and talk things out person to person, I'm sure things would go differently.

The internet is a great filter of intend and emotions, most is transmitted not via words, but via mimic, body language and subtext.

It's simpler to ignore or misinterpret something in the medium of the internet/anonymity than in real life.

But with a project that is worked on all over the world, thats mostly unfeasible I think, and so decisions will be made without taking the human aspect better into account.

Please note what I'm saying is highly simplified, I have no insight into the governance of freebsd, nor met any of their team members yet. My view on the whole thing is also filtered by the internet, reading just the reactions of the mailing list and other sources. It's just a very complex (human) issue in general.

You could look into the new divert-to mode which will not use the netmap driver, so it should have better performance in non-optimal environments.

https://docs.opnsense.org/manual/ips.html#general-setup

We're working on it.

Have a nice day,

Cedrik

Sorry for not responding earlier, glad you could figure it out :)

If you have the same issue best open a ticket for us in core to track it, link this thread as reference. I don't mind adding more start safety to KEA, as it's also a suggested tuning parameter in their mailing list.

https://github.com/opnsense/core/issues

There is also nothing quite like Poudriere or the whole ports ecosystem where you can build the whole system reproducibly and declaratively from source. The whole build ecosystem is different between FreeBSD and Linux.

In Linux, maybe NixOS can do it declaratively, but that is a very fickle beast.

The main issue isnt just to do some translation layers, its a multi layered issue through many different systems and dependencies.

I also do not miss systemd in the slightest to be honest. :D

So geht es mit caddy, wahrscheinlich mit ha-proxy irgendwie auch so ähnlich:

https://docs.opnsense.org/manual/how-tos/caddy.html#crowdsec-integration