Add support for the IPFW and/or IPF firewalls OR make pot firewall-agnostic

[debdrup]

The one thing missing from pot, I think, is making pot either capable of using either or both IPFW and IPF, since both have people who actively use and maintain them.

Another option which is arguably better but may involve more work (and changing ABI/KBI and would thus probably involve a major version bump?) would be to adopt a principle similar to that of blacklistd.
It uses a firewall-agnostic API where the sysadmin supplies the commands necessary for certain functions, and then that command is simply executed.
This would have the added benefit that if, say, npf (NetBSD Packet Filter by rmind@netbsd) was ever ported to FreeBSD, or another 4th firewall was added, it would be trivial to add support for these.

[pizzamig]

Thanks for show interest on this.
However what you ask, It's not easy.
the first thing I'd like to work is to rework the pf support using anchor. I can rework this part of the code to be "firewall independent". In this way, it should be easier to add support to other firewalls.

[debdrup]

Ah, I see - well, it doesn't have to be right now, and it's better to get it done properly when you're going to be doing it - so as long as it gets done, it doesn't have to be soon.
I think it would also give pot an advantage over many of the other similar tools, so there's something to consider. :)

[Crest]

IPFW tables could really simplify things because they're key-value maps instead of just sets and the mapped value(s) can be used as part of the argument to ipfw actions e.g. forward to this address and port. I' m willing to look into this. I suspect that everything pot needs can be expressed in IPFW with a short fixed set of rules.

[Crest]

I look into what firewall features pot uses so far and found this:

• IPv4 1:n NAT for bridges
• TCP port forwarding
  It also manages bridges and epair interfaces and handles dynamic IPv4 address allocation for vnet enabled jails.

Since pot already makes use of FreeBSD specific features here is how I would like to improve this:

• Reuse the existing rc.d code to offer flexible hooks.
• Have one directory per hook and sort the hooks with rcorder.
• The hooks can return these results: success, failure, continue. Processing of hooks continues in the order determined by rcorder until either a hook returns success or failure or all hooks have executed.
• Parameters are passed to hooks through environment variables with the prefix $POT_.
• The hooks are executed with /dev/null as standard input and inherit the standard error output.
• The standard output is used to return key=value pairs. Values must not contain newlines. The semantics of key reuse are either overwrite or append depending the key.
• The documentation for each type of hook should document all environment variables passed and the set of optional and required keys available to hooks.

This could at the very least extend the existing hooks for:

• prestart
• poststart
• prestop
• poststart

Additional hooks could be added to handle network interfaces (physical interface for alias and inherit, bridge+epair for vnet):

• setup (allocate network prefixes, assign host address, prepare firewall and routing for jails)
• teardown (restore firewall and routing, release host addresses and net prefixes after the addresses and routes have been removed)
• attach (assign jail addresses, write ip4/ip6=addr* to stdout)
• detach (release jail addresses)
• expose (open/forward ports even called if no ports have been exposed)
• unexpose (close ports)

Pot should include at least one default implementation for each type of hook to work out of the box and serve as example.

@pizzamig : How do you think about this design proposal?

[Crest]

An other question is how these hooks should be stored. Right now pot export doesn't preserve the hooks on the exported jail. This is a problem because for some setups these hooks are required e.g. to add jails to PF tables.

[pizzamig]

first the easy question: hooks are copied in the conf folder of the pot.
To make them part of an exported jail, you have to take the snapshot AFTER the set-hook.
pot export generates the image from the last available snapshot, not the current status.

Design proposal: honestly it seems very complicated to me and it needs a major rework.

My original idea about firewall was this: define a set of functions to use the firewall, kind of an API.
Then, provide an implementation for pf and another one for ipfw and let the user choose.

In general, I stand to support only 1 hook, it's a good way to extend pot and try new features, that at the end should be integrated in the framework.

Support multiple hooks needs a lot of work and time, that unfortunately I don't have right now...

[grembo]

first the easy question: hooks are copied in the conf folder of the pot.
To make them part of an exported jail, you have to take the snapshot AFTER the set-hook.
pot export generates the image from the last available snapshot, not the current status.

Design proposal: honestly it seems very complicated to me and it needs a major rework.

My original idea about firewall was this: define a set of functions to use the firewall, kind of an API.
Then, provide an implementation for pf and another one for ipfw and let the user choose.

In general, I stand to support only 1 hook, it's a good way to extend pot and try new features, that at the end should be integrated in the framework.

Support multiple hooks needs a lot of work and time, that unfortunately I don't have right now...

@pizzamig @Crest I feel like this is the kind of improvement that should come as a pull request from someone who is using pot in production and requiring that feature.

[Crest]

I asked because I have a use-case that isn't covered by the existing features e.g. UDP based services and automatic IPv6 aliases. Scripting around those limitations with the existing hooks and ansible is possible, but time consuming and fragile.

[Crest]

I just revisited the design and there is no reason to embed support for multiple hooks on a single jail/interface into pot. Should the user want this a hook can be used to loop over the other hooks with whatever merge and shortcut behaviour fits his usecase.