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

[Timo Buhrmester <fstd.lkml%gmail.com@localhost>]

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

From: Timo Buhrmester <fstd.lkml%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: tech-net%netbsd.org@localhost, rmind%netbsd.org@localhost
Subject: Re: kern/53962 (npf: weird 'stateful' behavior)
Date: Sun, 5 Apr 2020 04:32:32 +0200

 Hi, sorry for the late reply, I haven't had time to upgrade to netbsd-9.
 
 > Does the "stateful-all" keyword (in -current/netbsd-9) satisfy your use case?
 The short answer is no, or rather I don't know; something with the NAT seems broken.
 
 
 I've built a test setup with yesterday's -current with three machines invovled:
 
 Machine "client" has one interface (eth0, 192.168.3.2/24).
 It will try to connect to 5.9.82.75:25/tcp via "npfbox"
 
 Machine "npfbox" has two interfaces (vr1, 192.168.3.1/24 and vr0, 192.168.1.200/24)
 It will perform NAT 192.168.3.0/24 to 192.168.1.200 and forward to 192.168.1.1
 
 Machine "gateway" (192.168.1.1) is my internet gateway.
 
 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)
 
 vr1:     04:00:03.913162 IP 192.168.3.2.53200 > 5.9.82.75.25: Flags [S], seq 4038765496, win 64240, options [mss 1460,sackOK,TS val 1371479013 ecr 0,nop,wscale 7], length 0
 npflog1: 04:00:03.913232 IP 192.168.3.2.53200 > 5.9.82.75.25: Flags [S], seq 4038765496, win 64240, options [mss 1460,sackOK,TS val 1371479013 ecr 0,nop,wscale 7], length 0
 npflog1: 04:00:03.913323 IP 192.168.1.200.1046 > 5.9.82.75.25: Flags [S], seq 4038765496, win 64240, options [mss 1460,sackOK,TS val 1371479013 ecr 0,nop,wscale 7], length 0
 vr0:     04:00:03.913353 IP 192.168.1.200.1046 > 5.9.82.75.25: Flags [S], seq 4038765496, win 64240, options [mss 1460,sackOK,TS val 1371479013 ecr 0,nop,wscale 7], length 0
 vr0:     04:00:03.936635 IP 5.9.82.75.25 > 192.168.1.200.1046: Flags [S.], seq 698708591, ack 4038765497, win 65535, options [mss 1432,nop,wscale 4,sackOK,TS val 1 ecr 1371479013], length 0
 npflog1: 04:00:03.936683 IP 192.168.1.200.1046 > 192.168.1.200.1046: Flags [S.], seq 698708591, ack 4038765497, win 65535, options [mss 1432,nop,wscale 4,sackOK,TS val 1 ecr 1371479013], length 0
 npflog1: 04:00:03.936756 IP 192.168.1.200.1046 > 192.168.1.200.1046: Flags [R], seq 4038765497, win 0, length 0
 lo0:     04:00:03.936770 IP 192.168.1.200.1046 > 192.168.1.200.1046: Flags [R], seq 4038765497, win 0, length 0
 
 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
 
 Am I doing something wrong?
 
 Timo