On 6/23/23 13:19, Stephan Neuhaus wrote:
[...]
Some people have replied to this post off-list and
have made the entirely reasonable conjecture that the
packet changes its effective source address the moment
the match rule matches. With the changed source
address, the pass rule no longer matches. That is
entirely possible and agrees with all the experimental
evidence I have.
Still, I don't think that this is what's going on, for
the following reasons.
1. It is in conflict with the documentation. The FAQ
http://www.openbsd.org/faq/pf/nat.html says
match
When a packet traverses the ruleset and matches a match rule, any
optional parameters specified in that rule are remembered for future use
(made "sticky").
pass
This rule allows the packet to be transmitted. If the packet was
previously matched by a match rule where parameters were specified, they
will be applied to this packet. [...]
This makes it very clear that the nat-to in the match
rule is only "remembered for future use", and is
applied to the packet only when it is finally subject
to a pass rule.
Similarly, "The Book of pf", 3rd ed., has a match/pass
combo on p.53 that goes
match out on $ext_if inet from $localnet nat-to ($ext_if)
pass quick inet proto { tcp, udp } from $localnet to port $udp_services
As you can see, the pass rule has the packet's
original source specification $localnet, not the
natted-to $(ext_if).
2. The match/pass combo would be much less useful. If
the packet would immediately change its effective
source address to that of the outgoing interface, it
would for example become very hard in later rules to
distinguish between NATed packets and packets
originating on the firewall.
Cheers
Stephan
