Hi Zack
On 6/24/23 03:39, Zack Newman wrote:
There do appear to be contradictions in documentation as well as the pf
book. The Configuring NAT section is correct as you have seen with your
own rules.
I'm not sure about the Configuring NAT section being
correct. I still maintain that the documentation and
observed behaviour are different.
I now have the following small ruleset. The rules for
ports 22 and 53 are just so that I can do my
experiments over ssh. (Port 53 may not be necessary
but the blocked packets mess up my logs.) The em0
interface has the IPv4 address 192.168.0.2.
set skip on lo
block log all
pass in on em0 proto tcp to any port 22
pass out on em0 proto tcp from any port 22
pass on em0 proto udp from any port 53
pass on em0 proto udp to any port 53
pass in on athn0
match out log on em0 from athn0:network to any nat-to (em0)
#pass out log on em0 from athn0:network to any
pass out log on em0 from 192.168.0.2 to any
This causes packets from athn0 to pass and to be
correctly NATed. If I uncomment the penultimate line
and comment out the last line, the packets get matched
(as before), but then blocked by the catch-all rule 0.
This is consistent with the nat-to being applied
immediately after the match rule matches, EXCEPT that
the blocked packet is logged with a source address
inside athn0:network (192.168.3.0/24 in this case) and
not the NATed-to 192.168.0.2. For example:
Jun 24 10:24:46.498327 rule 0/(match) block out on em0:
192.168.3.32.54459 > 172.217.168.68.443: S 2479117865:2479117865(0) win
65535 <mss 1460,sackOK,timestamp 12197152 0,nop,wscale 8> (DF)
I now think that either the documentation is wrong, or
pf is wrong. At any rate, there seems to be a rather
serious disconnect between the two. The FAQ clearly
says:
When a packet is selected by a match rule, parameters (e.g. nat-to) in
that rule are remembered and are applied to the packet when a pass rule
matching the packet is reached.
This seems to me to imply that the nat-to in my match
rule should not be applied BEFORE the pass rule is
attempted, but only AFTER. This seems also to be the
point of these lines in the documentation:
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. [...]
I know that the documentation (at this time) ALSO
says:
match out on interface [af] \
from src_addr to dst_addr \
nat-to ext_addr [pool_type] [static-port]
[...]
pass out [log] on interface [af] [proto protocol] \
from ext_addr [port src_port] \
to dst_addr [port dst_port]
where the pass rule has ext_addr instead of src_addr,
but at least two people on t...@openbsd.org have
confirmed that this is a bug and have already
submitted a diff that replaces ext_addr with src_addr
in the pass rule, see
https://marc.info/?l=openbsd-tech&m=168714686620055&w=2
Should I be taking this to another mailing list?
Should I be submitting a bug report? Or am I just
really really dense and am just too stupid to read the
documentation correctly?
Cheers
Stephan
