From owner-freebsd-pf@FreeBSD.ORG Thu Feb 28 12:17:22 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C160E1065676 for ; Thu, 28 Feb 2008 12:17:22 +0000 (UTC) (envelope-from vchepkov@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA998FC25 for ; Thu, 28 Feb 2008 12:17:22 +0000 (UTC) (envelope-from vchepkov@gmail.com) Received: by rv-out-0910.google.com with SMTP id g13so2420252rvb.43 for ; Thu, 28 Feb 2008 04:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=HSl+SgHs/kF0aEHW4IrIgIjtSF1fpL8Ch7ziBmH0HrQ=; b=KaP8v6jBpDq7mEL7Mpo1r38fIo74tupD77hBQV1ucbEisYx4d9O3OlLpNccYLZsiytCLWUYKesbu5Uit+uE0lG8YD3u9xdGfU5iH2tEvJ9BWKDp67hrBYY+DdYo63IHL08mbBC7g5QT6eodUJH1dgtFQwcQjqsJxH8+vIfbawvg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fxHUkyzYD/C9T8iCo0KDA2j6aE+n2luighlLXTK8X2zRM37zyKrCQ+vaNYVzmR1dSsDlQgLBqtUG6CLlWHi8w4de06QIYqb4Yr4jEn0uJjINt7+Go9xcf2EhWQgu7dUdRHfaUy/8cqLrJ/Ghhd3uV/Dow18OnU1+gd1LPrwysq4= Received: by 10.141.179.5 with SMTP id g5mr5377487rvp.18.1204201041923; Thu, 28 Feb 2008 04:17:21 -0800 (PST) Received: by 10.141.51.9 with HTTP; Thu, 28 Feb 2008 04:17:21 -0800 (PST) Message-ID: <1635d77d0802280417j507e1476m1c0b7c3158156d@mail.gmail.com> Date: Thu, 28 Feb 2008 07:17:21 -0500 From: "Vadym Chepkov" To: "Daniel Hartmeier" In-Reply-To: <20080228063105.GC32592@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1635d77d0802271143u2aeb0b13we310ea1a611afaa8@mail.gmail.com> <6e6841490802271310o3e5976a4gef2cb507087c01b@mail.gmail.com> <1635d77d0802271346g4cf02b8et8bc74d16f6e97e45@mail.gmail.com> <1635d77d0802272002w6aaaa0ect164a64e136b969f5@mail.gmail.com> <20080228063105.GC32592@insomnia.benzedrine.cx> Cc: freebsd-pf@freebsd.org Subject: Re: floating keep state X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 12:17:22 -0000 I never implied that "floating" means "allow connection on all interfaces". Rules were created just to illustrate the situation, they are not part of "production" environment. In the state table you see packet going from source to destination #pfctl -ss self udp 10.10.10.1:53 <- 10.10.11.254:32772 NO_TRAFFIC:SINGLE It has word "self" in it, which I assume means "not bound to a particular interface", which is result of "floating" policy. I thought reply from destination to source would be allowed, isn't that what "state" mean? But instead, the packet was blocked by a rule 22:58:14.296965 rule 1/0(match): block in on xl0: 10.10.10.1.53 > 10.10.11.254.32772: 45616*-[|domain] Vadym On Thu, Feb 28, 2008 at 1:31 AM, Daniel Hartmeier wrote: > On Wed, Feb 27, 2008 at 11:02:08PM -0500, Vadym Chepkov wrote: > > > My question is, why the reply packet was blocked? > > It seems you're misunderstanding what 'floating state' means. > > It does NOT mean "allow connection on all interfaces". > > If a connection traverses two interfaces, you need to allow it on both, > creating two two separate state entries (one incoming, one outgoing). > > The 'floating' would come into play if you had more than two interfaces, > and the same connection would traverse all three of them, due to dynamic > routing. Without dynamic routing, you can pretty much forget about > floating states, they do nothing. > > The first problem in your ruleset is that it does not block by default. > Instead, the packet goes out through xl0 based on the implicit pass rule > and does not create a second state. > > When the reply comes back in on xl0, there is no matching state (the > first one created on xl1 does NOT match, as direction is reversed), and > no pass rule matches on that interface in this direction. Hence the > block. > > Add a default block, add a 'pass out ... keep state' rule, and it will > work. > > You probably thought floating states would do that, but they don't. > > Daniel >