[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-pf
Subject:    Re: Need stateless NAT
From:       Ryan McBride <mcbride () countersiege ! com>
Date:       2008-04-15 7:24:00
Message-ID: 20080415072400.GK23325 () countersiege ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]