[afnog] IPfw + natd

[Brian Candler]

On Fri, Dec 02, 2005 at 05:56:17PM +0100, Phil Regnauld wrote:
> On Fri, Dec 02, 2005 at 03:52:57PM +0000, Brian Candler wrote:
> > I found interactions between ipfw and natd to be really hard to handle apart
> > from the simplest cases. I have had to have one rule to handle outbound
> > traffic at one point in the ruleset, and another rule to handle inbound
> > traffic at a different point in the ruleset; it was a nightmare.
> 
> 	If one understands that packets go 4 times through the firewall
> 	with natd, in what directions, it suddenly makes more sense.

I understand it - I think so anyway :-)

It's hard for me to remember a concrete example of the nastiness I've had to
do, but I'll try to remember. To start with, suppose you want natd to apply
to some packets but not others, such as packets only from certain IP ranges.
Then you need something like:

    ipfw add 10 divert natd all from x.x.x.x to any out via fxp0
    ipfw add 20 divert natd all from any to any in via fxp0

This relies on natd passing unmolested inbound packets which it has no
state for, which is usually OK. However you can end up bypassing security
rules if you're not careful - so if you're combining this with firewall
policy you can get bitten. Making the second rule specific to the fxp0
interface ('all from any to y.y.y.y in via fxp0') helps, where y.y.y.y is
the fxp0 local address.

It gets more complicated if you want traffic from RFC1918 addresses *to*
RFC1918 addresses, which go via an IPSEC tunnel via fxp0, _not_ to be
subject to NAT, but outbound packet to the Internet (which also goes via
fxp0) to be NATted.

I know I've had to do really nasty things in certain circumstances, like
reverse natd's idea of what is 'in' and what is 'out':

    ipfw add 10 divert 8000 all from any to any out via fxp0
    ipfw add 20 divert 8001 all from any to any in via fxp0
    ...
    natd -i 8000 -o 8001 ...

It got stupid when I needed multiple natd's for multiple outbound IPSEC
tunnel interfaces, with different policies for which ranges to NAT and which
not.

I don't have an example to hand where I had to separate the 'in' and 'out'
rules with intervening rules, but I definitely did have to do that. You can
end up in a quagmire of writing ipfw rules specially to match the traffic as
it was before the NAT and as it was after the NAT.

Regards,

Brian.