thank you,
I haven't tried it yet, because my original intention was to use NetBSD
npf instead of FreeBSD pf in a large environment (HPC datacenter),
this because apparently npf can take advantage of multi-core CPUs way
better than PF on other *BSD systems.
I will test it and see if the negation effectively works.
Thanks a lot
Rick
On 6/1/24 1:24 PM, Martin Husemann wrote:
On Wed, May 29, 2024 at 11:33:28AM +0200, fddi wrote:
So for example, nat any clients from 172.16.10.0/23, 172.16.1.0/24 to any
desination NOT matching 131.241.0.0/16, thus traffic to 131.241.0.0/16 is
supposed to be routed and not natted.
$pub_if = "vioif0"
map $pub_if dynamic any -> inet4($pub_if) pass family inet4 from {
172.16.10.0/23, 172.16.1.0/24 } to ! 131.241.0.0/16
but this is what "npfctl validate" or "npfctl show" is showing:
map vioif0 dynamic any -> 131.154.4.29 pass family inet4 from {
172.16.10.0/23, 172.16.1.0/24 } to 131.241.0.0/16
The negation mark (!) is ignored
At quick glance it seems the generated bpf byte code is correct, but the
pretty printer used in "validate" and "show" misses the destination inversion
option (there is code that should show it, but it seems to be buggy).
You can see the difference between the version with and without the ! by
doing something like:
npfctl debug -c npf.conf > out.neg
then removing the ! and try again:
npfctl debug -c npf.conf > out.positive
and then diff -u the two out.* files.
Have you tried if your NAT works?
Please file a PR with the details, there defintively is a bug if
"show" or "validate" don't show a rule that could be used for input.
Martin