[afnog] IPfw + natd

[Phil Regnauld]

On Fri, Dec 02, 2005 at 07:25:44PM +0000, Brian Candler wrote:
> 
> 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

	Definitely, but that's quite normal so far.
	Except I would put "from any to me in via fxp0" on rule no.2

> This relies on natd passing unmolested inbound packets which it has no
> state for, which is usually OK.

	... or having more precise rules.  It's important to remember that
	if you're just outside the firewall, and have a route pointing
	to the inside net, NATD *will* allow those packets, unless you
	explicitly forbid them via a deny rule...

	(that's for those saying "NAT is secure").

> 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.

	The rule to remember is to put nat rules as early as possible, after
	spoofing protection, and THEN handle traffic to/from rfc1918 addresses
	as anything else.

> 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.

	skipto and rule groups can be of a big help to clean up the picture --
	otherwise it can indeed become tricky to understand.

> 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 ...

	You should be able to do that with -reverse.

> 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.

	How do you do that with PF, though ?

> 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.

	If possible, try to NAT early and filter everything later.

	Another one that bites: ipfw pipes implicitly allow ALL traffic
	for the matching rule, UNLESS net.inet.ip.fw.one_pass is set to 0.