Re: kern/53962 (npf: weird 'stateful' behavior)

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Timo Buhrmester <fstd.lkml%gmail.com@localhost> wrote:
> <...>
> 
> Here's the npf.conf on "npfbox"
> | alg "icmp"
> | 
> | map vr0 dynamic 192.168.3.0/24 -> 192.168.1.200
> | 
> | procedure "logb" { log: npflog0 } #blocked
> | procedure "logp" { log: npflog1 } #passed
> | 
> | group "lo0" on lo0 {
> |         pass in final all apply "logp"
> |         pass out final all apply "logp"
> | }
> | 
> | group "internalnet" on vr1 {
> |         pass stateful-all in final family inet4 proto tcp from
> | 192.168.3.0/24 to 5.9.82.75 port 25 apply "logp" }
> | 
> | group default {
> |         block in final all apply "logb"
> |         block out final all apply "logb"
> | }
> 
> Here's what currently happens, tcpdumping on all of npfbox's interfaces:
> (note that npflog1 logs *passed* packets, also note no traffic at all on
> npflog0)
> 
> <...>
> 
> So it seems that the "de-NATting" on the reverse path is broken.
> I don't understand why the SYN/ACK doesn't show up on lo0, but I guess it
> doesn't matter much

Just a general update: I have various NPF fixes and improvements which
will soon be merged to NetBSD.

On the 'stateful-all' problem: while the state will be picked up on the
other interface (vr0), the NAT policy will operate using the *initial*
connection direction which was established on vr1 as inbound.  So, the
NAT mechanism doesn't recognize the SYN-ACK packet as returning/reverse.
Such behaviour is unhelpful and, instead, NPF should probably capture the
connection direction at the point of the NAT entry creation and perform
the translation based on that (rather than using the original connection
direction at the point of state creation).

There are more implications here.. I am going to add configuration-wide
parameters to give user more flexibility on connection state behaviour.

-- 
Mindaugas