nat pass and state

I have these rules (and others) in pf.conf:

nat pass on $ext_if from $int_net to any -> ($ext_if)

block in all
block out all

I cannot connect to websites unless I also add:

pass proto { tcp, udp } from any to any port http keep
state

My understanding is that nat rules are inherently stateful. 
I also 
understand that a packet that matches state bypasses filter
rules.  A 
hit on a web page should generate a state on the way out and
then match 
that state on the way back in, avoiding the block rules.  By
testing, I 
show that the pass http rule is needed to complete the
connection.

Would someone please explain why the nat rule is not
sufficient to allow 
me to access a web page?  I must have a gross conceptual
error on how PF 
works.  This is too simple, but I just don't get it.

Regards,
Jason
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

On Tue, May 20, 2008 at 06:27:47PM -0700, Jason C. Wells
wrote:
> I have these rules (and others) in pf.conf:
>
> nat pass on $ext_if from $int_net to any ->
($ext_if)
>
> block in all
> block out all
>
> I cannot connect to websites unless I also add:
>
> pass proto { tcp, udp } from any to any port http keep
state
>
> My understanding is that nat rules are inherently
stateful.  I also 
> understand that a packet that matches state bypasses
filter rules.  A hit 
> on a web page should generate a state on the way out
and then match that 
> state on the way back in, avoiding the block rules.  By
testing, I show 
> that the pass http rule is needed to complete the
connection.
>
> Would someone please explain why the nat rule is not
sufficient to allow me 
> to access a web page?  I must have a gross conceptual
error on how PF 
> works.  This is too simple, but I just don't get it.

I believe it's because pf(4) doesn't make assumptions about
what you
want to filter.  NAT is stateful (it has to be, because
packets are
being re-written, and the WAN-side port numbers are going to
be
different than the LAN-side), but filtering rules still
apply **after**
the translation has been done.

What's happening is that your nat rule results in pf
re-writing the
packet, then the packet is immediately blocked by one of
your block
rules (I'm assuming "block out").

The pf.conf manpage documents this, more or less:

     Since translation occurs before filtering the filter
engine will see
     packets as they look after any addresses and ports have
been translated.
     Filter rules will therefore have to filter based on the
translated
     address and port number.  Packets that match a
translation rule are only
     automatically passed if the pass modifier is given,
otherwise they are
     still subject to block and pass rules.

-- 
| Jeremy Chadwick                                jdc at
parodius.com |
| Parodius Networking                       http://www.parodius.com/
|
| UNIX Systems Administrator                  Mountain View,
CA, USA |
| Making life hard for others since 1977.              PGP:
4BD6C0CB |

_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

Jeremy Chadwick wrote:

> I believe it's because pf(4) doesn't make assumptions
about what you
> want to filter.  NAT is stateful (it has to be, because
packets are
> being re-written, and the WAN-side port numbers are
going to be
> different than the LAN-side), but filtering rules still
apply **after**
> the translation has been done.
> 
> What's happening is that your nat rule results in pf
re-writing the
> packet, then the packet is immediately blocked by one
of your block
> rules (I'm assuming "block out").
> 
> The pf.conf manpage documents this, more or less:
> 
>      Since translation occurs before filtering the
filter engine will see
>      packets as they look after any addresses and ports
have been translated.
>      Filter rules will therefore have to filter based
on the translated
>      address and port number.  Packets that match a
translation rule are only
>      automatically passed if the pass modifier is
given, otherwise they are
>      still subject to block and pass rules.

I guess my misunderstanding comes in where the pass modifier
is 
concerned. I also have a weak understand of what
"state" actually means. 
     The "automatically passsed" part of your
citation isn't 
automatically passing.

I think I'll just drop the pass modifier on the NAT rule. 
Then it 
becomes precisely clear to me that I need a filter rule
after the nat rule.

Regards,
Jason
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

On Tue, May 20, 2008 at 10:03:32PM -0700, Jason C. Wells
wrote:
> Jeremy Chadwick wrote:
>
>> I believe it's because pf(4) doesn't make
assumptions about what you
>> want to filter.  NAT is stateful (it has to be,
because packets are
>> being re-written, and the WAN-side port numbers are
going to be
>> different than the LAN-side), but filtering rules
still apply **after**
>> the translation has been done.
>>
>> What's happening is that your nat rule results in
pf re-writing the
>> packet, then the packet is immediately blocked by
one of your block
>> rules (I'm assuming "block out").
>>
>> The pf.conf manpage documents this, more or less:
>>
>>      Since translation occurs before filtering the
filter engine will see
>>      packets as they look after any addresses and
ports have been translated.
>>      Filter rules will therefore have to filter
based on the translated
>>      address and port number.  Packets that match a
translation rule are only
>>      automatically passed if the pass modifier is
given, otherwise they are
>>      still subject to block and pass rules.
>
> I guess my misunderstanding comes in where the pass
modifier is concerned. 
> I also have a weak understand of what "state"
actually means.     The 
> "automatically passsed" part of your citation
isn't automatically passing.

Oh!  I'm sorry, I missed the "pass" word that was
in your nat rule.  I
don't ultimately know what that does internally to pf. 
There does not
appear to be any actual documentation on what the
"pass" entry in a nat
rule actually does.

This sounds like it could be a bug; even the pf examples in
/usr/share/examples/pf don't use "pass" in a nat
rule.  I'll leave the
bug comment up to the pf experts here to analyse, though.

-- 
| Jeremy Chadwick                                jdc at
parodius.com |
| Parodius Networking                       http://www.parodius.com/
|
| UNIX Systems Administrator                  Mountain View,
CA, USA |
| Making life hard for others since 1977.              PGP:
4BD6C0CB |

_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason C. Wells <jcwhighperformance.net> wrote:
>
> Would someone please explain why the nat rule is not
sufficient to
> allow me to access a web page?  I must have a gross
conceptual error
> on how PF works.  This is too simple, but I just don't
get it.

The first packet arrives on $int_if and is blocked by
"block in all". 
It never has a chance to route to $ext_if, and thus never
matches the
nat rule.  The "nat pass" does not apply because
the initial packet is
not arriving on $ext_if so it can't match the rule (yet).

You have to allow the connection in on $int_if first, then
when it
routes out $ext_if it will match the nat rule and set up
state.

- -- 
David DeSimone == Network Admin == foxverio.net
"This email message is intended for the use of the
person to whom
 it has been sent, and may contain information that is
confidential
 or legally protected.  If you are not the intended
recipient or have
 received this message in error, you are not authorized to
copy, dis-
 tribute, or otherwise use this message or its attachments. 
Please
 notify the sender immediately by return e-mail and
permanently delete
 this message and any attachments.  Verio, Inc. makes no
warranty that
 this email is error or virus free.  Thank you." 
--Lawyer Bot 6000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFIM9+WFSrKRjX5eCoRAjWPAJ9+rZ6aqUVEEiRulw+nQD2swM84QACc
DE5e
x0MSmBXcgbFqPmUkjRIAO60=
=bzw3
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-pffreebsd.org mailing list

http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"