Trevor: I mostly agree with your analysis, and without more information about the actual problem Adam is trying to solve I'm chalking it all up to horrendous network design.
That being said, part of PFs usefulness is it's ability to make some horrendous network situations manageable. So I don't think the ugliness of the problem precludes us solving it... especially since some of the actual issues with this (cost of table/ruleset updates, rule matching performance) are issues that affect many other pf users. A couple of inline comments: On Mon, Apr 14, 2008 at 07:49:43PM -0700, Trevor Talbot wrote: >> Maybe this will change in the future to where I may need 1:n mapping? > > Note that 1:N requires flow tracking, even if it's only as granular as > remote:internal/remote:external address pairs. Somewere low down on my todo list is to use the src-nodes code in pf to handle M:N binat mappings, where M can be smaller than N, so long as no more than M nodes are active in a given period. In fact, something like this could possibly solve Adam's problem, given a tool to add/remove src-node entries. > In order to get pf doing what you want, you'll essentially have to cripple > the state engine to first remove the firewalling logic, then scale back the > amount of state tracked until it's as dumb as you want. Then add an > interface to add entries to the state table itself, instead of using the > ruleset. Or build your own engine based off of pf's state organization. I don't think it's necessary to cripple any of pf's current behaviour to support what Adam wants, but it's certainly not going to be a trivial change to do it cleanly. That being said, a change which result in a simplification of this code is definately something we'd consider, and there's definately room for that in this code. And to Adam's comment: >> I would like preface my inline replies with stating what my original goal >> was, and still is, in starting this thread: >> >> I want to pursuade the pf community that stateless NAT is a >> desired feature and should be part of the core code. :) My >> use-case is just one example of how this can be a useful >> feature. I'm not convinced of this yet, but I agree that it's an interesting problem. I'm looking forward to seeing your reply to Trevor's analysis. -Ryan