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

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

The following reply was made to PR kern/53962; it has been noted by GNATS.

From: Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>
To: Timo Buhrmester <fstd.lkml%gmail.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, tech-net%netbsd.org@localhost
Subject: Re: kern/53962 (npf: weird 'stateful' behavior)
Date: Fri, 15 May 2020 20:30:10 +0100

 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