>Number:         28651
>Category:       kern
>Synopsis:       NAT in pf slow with TCP
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 14 08:09:00 +0000 2004
>Originator:     Teemu Rinta-aho
>Release:        2.9.11 (December 13 2004)
>Organization:
>Environment:
NetBSD/i386 2.99.11 (FW) #0: Mon Dec 13 12:30:15 EET 2004
>Description:
I have a simple 2-interface firewall/NAT box which is running NetBSD -current. ipfilter works just fine, but when trying pf, I have problems with NATed TCP connections. They kind of work, but *extremely* slowly. ICMP delay is the same for both ipfilter and pf. I see no blocked packets at pflog0, I see no error messages, and the state table looks ok. I have no idea where the packets are delayed. TCP from the firewall machine itself works fine so the problem is probably in the NAT & TCP.

I have put debug information available to my web page:

http://www.rinta-aho.org/network.html (my network)
http://www.rinta-aho.org/pr-pf/FW (kernel config, derived from GENERIC)
http://www.rinta-aho.org/pr-pf/dmesg (dmesg)
http://www.rinta-aho.org/pr-pf/ifconfig (ifconfig -a)
http://www.rinta-aho.org/pr-pf/ipf.conf (ipfilter config)
http://www.rinta-aho.org/pr-pf/ipnat.conf (ipnat config)
http://www.rinta-aho.org/pr-pf/pf.conf (pf config)
http://www.rinta-aho.org/pr-pf/private_nets (included from pf.conf)
http://www.rinta-aho.org/pr-pf/rc.conf (rc.conf)
http://www.rinta-aho.org/pr-pf/routes (netstat -rn)

This file shows the progress of the pf state tables while
trying to open a web page from the 10.0.0.10 machine. 

http://www.rinta-aho.org/pr-pf/states

The web page never loaded in time, but you can see that the TCP state
looks correct, but it takes awful lot of time to go even past the
SYN state. With ipfilter, the same web page loads in a blink
of an eye.

Note that I have compiled both ipfilter and pf to the same
kernel. I tried with a kernel with only pf some time ago but
the situation was exactly the same, so I don't think the reason
is a conflict between ipfilter and pf.
>How-To-Repeat:
I can do it any time:

1. ipfilter stop
2. pf start
>Fix: