Re: pf NAT confusion

[Ben Goren <ben@trumpetpower.com>]

On Thu, Apr 04, 2002 at 11:17:21AM -0500, Joel Schander wrote:

> > Because  of the  interactions of  NAT and  state keeping,  the
> > general method  to accomplish  what you describe  is basically
> > the  same as  what's done  with a  bridging firewall:  pick an
> > interface to filter on, and let everything else through on the
> > other(s). You could,  for example,  let everything  go through
> > the Internet  side of the  firewall, but only  permit selected
> > outbound  packets  to  your  servers  (with  keep  state)  and
> > selected  inbound  packets  from  your  proxy  server  on  the
> > workgroup  network. You could  still reject  all non-routeable
> > addresses, spoofs,  and the like  that appear on  the Internet
> > side.
>
> As I mentioned,  we saw that NATted traffic  passed through just
> fine if we opened outbound  traffic on the Net-side interface of
> the  firewall, but  that the  connection  was never  made if  we
> merely relied  on the rule  of our workgroup interface.   If the
> only solution  to this problem is  to open all traffic  from the
> firewall, that  will resolve  the problem  we presently  want to
> solve,  as the  outbound server  network traffic  is restricted;
> however, the  solution is  not elegant or  ideal.  The  setup we
> desire did work  in IP Filter, but the FAQ  does not mention the
> behavior we're seeing as a difference between the two, so either
> it's not (yet?)  supported or I'm missing something  the FAQ and
> manpages -- which are generally excellent -- haven't clued me in
> on.

I think  you are missing  something. Assuming a firewall  with two
NICs, packets can  come from three places:  computers connected to
one interface, another interface, or the firewall itself.

If you  have to  worry about packets  originating on  the firewall
itself, you're screwed; end of story.

If a  packet is coming from  the internal network on  the internal
interface (for example), then a pass/block in rule on the internal
interface will be sufficient to determine its ultimate fate.

If you block incoming packets  on the Internet interface then they
never  have a  chance  to get  sent out;  thus  nobody can  bounce
packets off your router, even if you permit all outgoing packets.

Therefore, allowing outbound traffic  on the Internet interface is
in no  way a  security concern, provided  the traffic  is properly
filtered on the internal interface.

I think part  of your confusion comes from  the difference between
state handling  in pf and ipf. (At  least, that was a  big part of
the confusion for me when I was  trying to figure this out for the
first time.) In ipf, the state  table is consulted for all packets
on all interfaces.   If you create state on an  incoming packet on
the internal interface,  the state is remembered  for the matching
incoming packet on the Internet interface. By contrast, pf's state
tables are interface specific.  Although state was created for the
incoming packet  on the  internal interface,  pf knows  nothing of
it  when  the matching  packet  arrives  inbound on  the  Internet
interface. It  *does*  recognize  it  when it's  outbound  on  the
internal interface.

NAT,  of course,  just starts  throwing monkey  wrenches into  the
mess.  Trying to keep straight what the source and destination IPs
are on which interface still makes my head hurt.

You could, if  you like, have duplicating  state-creating rules on
both interfaces--that is:

    pass in on $Internal_IF \
        proto tcp \
	from $Internal_Net \
	to any \
	port { ssh, www, https } \
	flags S/SA \
	keep state

    pass out on $Internet_IF \
        proto tcp \
	from $NAT_Net \
	to any
	port { ssh, www, https } \
	flags S/SA \
	keep state

This, however, gains you nothing  in terms of security. Indeed, it
costs you: it rules are more  complex and harder to maintain, thus
leading to an  increased potential for mistrakes. It'll  also be a
bit more load on the filter, again for no gain.

If,  on the  other hand,  you keep  the first  rule untouched  and
replace the second with ``pass  out quick on $Internet_IF from any
to any''  then you get  the same end result--assuming,  of course,
you have the proper anti-spoofing rules elsewhere in the file.

Trust me  on this one:  you really do  want to allow  all outgoing
traffic on the Internet interface  and do your policy filtering on
the internal one. But if you still don't understand why, certainly
ask questions!

> Joel

Good luck,

b&

--
Ben Goren
 mailto:ben@trumpetpower.com
 http://www.trumpetpower.com/
 icbm:33o25'37"N_111o57'32"W

[demime 0.98d removed an attachment of type application/pgp-signature]