From owner-freebsd-pf@FreeBSD.ORG  Sun Dec  7 09:46:34 2014
Return-Path: <owner-freebsd-pf@FreeBSD.ORG>
Delivered-To: freebsd-pf@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id BE1992B1
 for <freebsd-pf@freebsd.org>; Sun,  7 Dec 2014 09:46:34 +0000 (UTC)
Received: from mic.frontdam.com (mic.frontdam.com [37.247.48.72])
 by mx1.freebsd.org (Postfix) with SMTP id 197C1B1D
 for <freebsd-pf@freebsd.org>; Sun,  7 Dec 2014 09:46:33 +0000 (UTC)
Received: (qmail 76721 invoked by uid 0); 7 Dec 2014 09:39:50 -0000
Received: from unknown (HELO ?192.168.178.20?)
 (m.mazzucchi@keencons.com@unknown)
 by unknown with SMTP; 7 Dec 2014 09:39:50 -0000
From: Michele Mazzucchi <m.mazzucchi@keencons.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: TCP retransmission on rdr pass or nat pass
Message-Id: <632B9CC6-AF5D-45A2-A26F-C50220F36A56@keencons.com>
Date: Sun, 7 Dec 2014 10:39:41 +0100
To: freebsd-pf@freebsd.org
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Mailer: Apple Mail (2.1993)
X-BeenThere: freebsd-pf@freebsd.org
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: "Technical discussion and general questions about packet filter
 \(pf\)" <freebsd-pf.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-pf>,
 <mailto:freebsd-pf-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-pf/>
List-Post: <mailto:freebsd-pf@freebsd.org>
List-Help: <mailto:freebsd-pf-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-pf>,
 <mailto:freebsd-pf-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Dec 2014 09:46:34 -0000

Hello folks,

A few weeks ago I noticed random resets in ssh connections. Commands
generating short response sequences were unaffected, while those =
producing
much output (e.g. scp or cat) would reset the ssh connection.

Log messages going "pf: BAD state: TCP in wire=E2=80=9D helped tracking =
the issue
down to PF. I broke down a =E2=80=9Crdr=E2=80=9D rule from

rdr pass proto tcp from any to $jail2_pubip port $jail2_tcpports -> =
$jail2_privip

to

rdr proto tcp from any to $jail2_pubip port $jail2_tcpports -> =
$jail2_privip
[=E2=80=A6 ; block in log ; pass out quick]
pass in quick proto tcp from any to $jail2_privip port $jail2_tcpports

This surprisingly solved the issue. I=E2=80=99m not clear here: =
=E2=80=9Cpass=E2=80=9D rules now default
to =E2=80=9Ckeep state=E2=80=9D, but this seems to only apply when they =
belong to the =E2=80=9CFiltering=E2=80=9D
region. What=E2=80=99s their behavior when they decorate RDR rules?

Also, why does the lack of a state produce such unpredictable resets?

cheers
-m=