On Sat, Apr 01, 2006 at 03:28:36PM -0500, Gabriel Wachman wrote:
> Everything I know about PF is taken from the PF/NAT FAQ's, and the pf
> man page.
>
> Suppose you are using NAT as follows:
> nat on $ext_if from $int_if:network to ! $int_if:network -> ($ext_if)
>
> where $ext_if and $int_if are the external and internal interfaces of
> the firewall, respectively. For the purposes of this discussion, assume
> that this firewall has only the two interfaces, and is only
> filtering/translating between the $int_if:network and the Internet. In
> other words, it doesn't filter/translate any other traffic.
>
> If NAT translation happens BEFORE any filter rules are evaluated (see
> http://www.openbsd.org/faq/pf/nat.html), then wouldn't it be true that
> an outbound packet from the internal network will be seen by the
> filtering engine as a packet with source IP of the firewall?
No, because the filtering engine is smart enough to 'remember' the
original packet.
However, it will be seen as such by, for instance, another box on the
external network.
> Maybe an example will help illustrate my question:
>
> Looking at /usr/share/pf/faq-example1:
> <snip>
> nat on $ext_if from $int_if:network to any -> ($ext_if)
> <snip>
> pass in on $int_if from $int_if:network to any keep state
> <snip>
>
> Why is that second rule necessary? NAT translates any Internet-bound
> packets so that they have a source IP of the firewall so it would seem
> that this rule never gets evaluated. From my understanding, the
> filtering engine should only see packets with source IPs of the
> firewall, or destination IPs of the internal network, as that is all
> that will be left if NAT translates everything first.
As noted above, the filtering engine is a little smarter than this.
nat pass would be a shorter way to write the above, by the way.
Joachim
