-
-
Notifications
You must be signed in to change notification settings - Fork 381
Port ipset to BSD pf tables #144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Hi, so your code looks nice. The issue is not the ipset addition, but that I need to talk about the general approach. It modifies the contract API of the modules, so I think it is best if I talk with my colleagues about it. And figure out what it is that we want from it, what you have done could be that (and it looks fine & a lot of work too). |
Ping ? |
ping? I just merged again. |
This functionality would be incredibly useful as a lot of BSD systems that are used as routers/firewalls use Unbound as its primary DNS resolver, for example OPNsense and pfSense. Thanks. |
FreeBSD provides the |
Maybe I should have described the use case: making firewall decisions based on domain names (A and AAAA responses) by populating (pf tables or ipset) with resolved IPs. I can’t figure out how |
There is a modified version of this patch in #1098 . I tried to remove some of the changes to other parts of the code, but it is nice to keep the startup capability for modules to get privileged items. |
Thank you for the patch! The modified version has been merged and it is in the code repository. |
On OpenBSD packet filter tables provide similar functionality to linux netfilter ipset. The second commit adds support for them.
Since the pf is manipulated by
ioctl()
on/dev/pf
,/dev/pf
needs to be opened before privileges are dropped. The first commit renames the modules's init functions to setup and allows modules to implement an init funtion which is run once before privileges are dropped. One unwanted side effect of this change is that now on reload by -HUP signal the ordering of the modules mustn't change.This is not yet well tested, but feedback on whether the general approach is acceptable is highly welcome.