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

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

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