Date: Thu, 18 Oct 2018 11:11:52 -0700 From: "Kristof Provost" <kristof@sigsegv.be> To: "Andreas Longwitz" <longwitz@incore.de> Cc: freebsd-pf@freebsd.org Subject: Re: rdr pass for proto tcp sometimes creates states with expire time zero and so breaking connections Message-ID: <C4D1F141-2979-4103-957F-F0314637D978@sigsegv.be> In-Reply-To: <5BC51424.5000309@incore.de> References: <5BC51424.5000309@incore.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15 Oct 2018, at 15:26, Andreas Longwitz wrote:
> On two of my FreeBSD 10 (r338093) firewall servers some incoming ssh
> connections stopped to work because pf started to create states with
> expire time zero (instead of 86400 sec) for translation statements
> like
>
> rdr pass on em0 proto tcp from any to myip port 8022 --> 10.0.0.254
>
> Therefore a command given on a remote server like
>
> ssh -p 8022 myip sleep 15
>
> did not return, because the created state for the connection was
> purged
> by pf (interval 10 sec) before 15 seconds. If I replace the rdr pass
> rule with a rdr rule and a separate filter pass rule then the created
> state always has expire time 24h and everything is ok.
>
> I have tried to analyze the bug in the rdr pass rule. Immediately
> after
> starting the above ssh command on the remote sever I see with pfctl
> -vss
> the sreated state on my firewall machine:
>
> all tcp 10.0.0.254:8022 (myip:8022) <- remoteip:59233
> ESTABLISHED:ESTABLISHED
> [1443872812 + 66608] wscale 6 [1365307391 + 66560] wscale 3
> age 00:00:00, expires in 00:00:00, 13:12 pkts, 2955:3306 bytes
>
> and a DTrace script running at the same time gives
>
> 3 19323 pfsync_state_export:entry
> creation=4491391. expire=4491391, state_timeout=2
> 3 16459 pf_state_expires:entry
> state_timeout=86400,
> start_timeout=6000, end_timeout=12000 states=882
> 3 17624 counter_u64_fetch:entry
> 3 17625 counter_u64_fetch:return
> returncode (states_cur)=4294967248 = 0xffffffd0
> 3 16460 pf_state_expires:return
> returncode=4491391
> 3 19324 pfsync_state_export:return
> creation=0. expire=0, syncstate_timeout=2
> 0 12730 pfioctl:return
> returncode=0, time_uptime=4491391
>
> So pf_state_expires() returns the value time_update and therefore
> pfsync_state_export() gives expire zero. Reason for this is the very
> big
> (means negative) value returned by the function counter_u64_fetch()
> for
> states_cur. This variable is of type uint64_t and only incremented and
> decremented by the macros STATE_INC_COUNTERS and STATE_DEC_COUNTERS.
>
I wonder if there’s an integer overflow in the of_state_expires()
calculation.
The OpenBSD people have a cast to u_int64_t in their version:
timeout = (u_int64_t)timeout * (end - states) / (end - start);
Perhaps this would fix your problem? (Untested, not even compiled)
if (end && states > start && start < end) {
if (states < end) {
timeout = (uint64_t)timeout * (end - states) / (end - start);
return (state->expire + timeout;
}
else
return (time_uptime);
}
return (state->expire + timeout);
}
Best regards,
Kristof
From owner-freebsd-pf@freebsd.org Fri Oct 19 20:56:13 2018
Return-Path: <owner-freebsd-pf@freebsd.org>
Delivered-To: freebsd-pf@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08703FE5BBC
for <freebsd-pf@mailman.ysv.freebsd.org>; Fri, 19 Oct 2018 20:56:13 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org
[IPv6:2001:1900:2254:206a::50:5])
by mx1.freebsd.org (Postfix) with ESMTP id 990088D39E
for <freebsd-pf@freebsd.org>; Fri, 19 Oct 2018 20:56:12 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: by mailman.ysv.freebsd.org (Postfix)
id 5A782FE5BBA; Fri, 19 Oct 2018 20:56:12 +0000 (UTC)
Delivered-To: pf@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1EBC4FE5BB6
for <pf@mailman.ysv.freebsd.org>; Fri, 19 Oct 2018 20:56:12 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org
[IPv6:2001:1900:2254:206a::19:3])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mxrelay.ysv.freebsd.org",
Issuer "Let's Encrypt Authority X3" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id B43068D39C
for <pf@FreeBSD.org>; Fri, 19 Oct 2018 20:56:11 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org (kenobi.freebsd.org
[IPv6:2001:1900:2254:206a::16:76])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client did not present a certificate)
by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 0DB75F4F7
for <pf@FreeBSD.org>; Fri, 19 Oct 2018 20:56:11 +0000 (UTC)
(envelope-from bugzilla-noreply@freebsd.org)
Received: from kenobi.freebsd.org ([127.0.1.118])
by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9JKuApd016861
for <pf@FreeBSD.org>; Fri, 19 Oct 2018 20:56:10 GMT
(envelope-from bugzilla-noreply@freebsd.org)
Received: (from www@localhost)
by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9JKuAvP016860
for pf@FreeBSD.org; Fri, 19 Oct 2018 20:56:10 GMT
(envelope-from bugzilla-noreply@freebsd.org)
X-Authentication-Warning: kenobi.freebsd.org: www set sender to
bugzilla-noreply@freebsd.org using -f
From: bugzilla-noreply@freebsd.org
To: pf@FreeBSD.org
Subject: [Bug 122773] [pf] pf doesn't log uid or pid when configured to
Date: Fri, 19 Oct 2018 20:56:11 +0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Base System
X-Bugzilla-Component: kern
X-Bugzilla-Version: 7.0-RELEASE
X-Bugzilla-Keywords:
X-Bugzilla-Severity: Affects Only Me
X-Bugzilla-Who: kp@freebsd.org
X-Bugzilla-Status: Open
X-Bugzilla-Resolution:
X-Bugzilla-Priority: Normal
X-Bugzilla-Assigned-To: pf@FreeBSD.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-122773-16861-kSm4U5fbNs@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-122773-16861@https.bugs.freebsd.org/bugzilla/>
References: <bug-122773-16861@https.bugs.freebsd.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: freebsd-pf@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Technical discussion and general questions about packet filter
\(pf\)" <freebsd-pf.freebsd.org>
List-Unsubscribe: <https://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: <https://lists.freebsd.org/mailman/listinfo/freebsd-pf>,
<mailto:freebsd-pf-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Oct 2018 20:56:13 -0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D122773
Kristof Provost <kp@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kp@freebsd.org
--- Comment #5 from Kristof Provost <kp@freebsd.org> ---
It looks like the kernel side of this (at least for uid) is present.
I've updated the patch:
diff --git a/contrib/tcpdump/print-pflog.c b/contrib/tcpdump/print-pflog.c
index 265efd3c866..38201c55ee3 100644
--- a/contrib/tcpdump/print-pflog.c
+++ b/contrib/tcpdump/print-pflog.c
@@ -97,8 +97,12 @@ pflog_print(netdissect_options *ndo, const struct pflogh=
dr
*hdr)
else
ND_PRINT((ndo, "rule %u.%s.%u/", rulenr, hdr->ruleset,
subrulenr));
- ND_PRINT((ndo, "%s: %s %s on %s: ",
- tok2str(pf_reasons, "unkn(%u)", hdr->reason),
+ ND_PRINT((ndo, "%s", tok2str(pf_reasons, "unkn(%u)", hdr->reason)));
+
+ if (hdr->uid !=3D UID_MAX)
+ ND_PRINT((ndo, " [uid %u]", (unsigned)hdr->uid));
+
+ ND_PRINT((ndo, ": %s %s on %s: ",
tok2str(pf_actions, "unkn(%u)", hdr->action),
tok2str(pf_directions, "unkn(%u)", hdr->dir),
hdr->ifname));
A simple ping now produces this:
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture
size 262144 bytes
00:00:00.000000 rule 0/0(match) [uid 1001]: pass out on vtnet0: (tos 0x0, =
ttl
64, id 20885, offset 0, flags [none], proto UDP (17), length 55)
172.16.2.2.64345 > 172.16.2.1.53: [bad udp cksum 0x5c58 -> 0x964f!] 271=
30+
A? google.be. (27)
00:00:00.071014 rule 0/0(match) [uid 0]: pass out on vtnet0: (tos 0x0, ttl=
64,
id 63862, offset 0, flags [none], proto ICMP (1), length 84)
172.16.2.2 > 172.217.18.163: ICMP echo request, id 35102, seq 0, length=
64
If anyone is still interested in this, can you test it and let me know if t=
his
works for you?
--=20
You are receiving this mail because:
You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C4D1F141-2979-4103-957F-F0314637D978>