From owner-freebsd-pf@FreeBSD.ORG Thu Feb 28 15:12:15 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 4B9FF1065695 for ; Thu, 28 Feb 2008 15:12:15 +0000 (UTC) (envelope-from vchepkov@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by mx1.freebsd.org (Postfix) with ESMTP id D914E8FC1A for ; Thu, 28 Feb 2008 15:12:14 +0000 (UTC) (envelope-from vchepkov@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so5249398wri.3 for ; Thu, 28 Feb 2008 07:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=sIUs9/pln4FkqVhh+WMTk7W6iTw4gQbNiuW6BhS/vR4=; b=M9crejzL4FgJdopMkPSlrEHbZ+MV3KlJigyW2458Wtx/r4524ib9nspygbvOcTI0gRDi50EPCMji3LIYRw6vj+HRw31/9LPL/DnAMSWe5Ovzhh6zJVDx5Dr2X2gWC8n54LpcUG8xuzP1bUYbddxfzYwvxumdb6Rty5wQHUt9Xws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=sEaVGvBAOB1Gs9BW6a3Fop5C7PfPzbL6uJ++j5qwiYnxyII8+R+2gyq/niyp0W4qEpMrW/CMvzVfdqeeQ5Dd5oPO51VAlpsrDsq9XSpEdoYku2vJlFUiolhtipY6NB7bGa6ydWsqMZFE9WcYgtZIczs+JtlqL3wzmyR2gzVPGPw= Received: by 10.140.251.1 with SMTP id y1mr5535700rvh.149.1204211531851; Thu, 28 Feb 2008 07:12:11 -0800 (PST) Received: from xp ( [72.86.47.124]) by mx.google.com with ESMTPS id g5sm11283525wra.31.2008.02.28.07.12.10 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Feb 2008 07:12:10 -0800 (PST) Message-ID: <002701c87a1c$51a9bad0$050a0a0a@chepkov.lan> From: "Vadym Chepkov" To: "Kian Mohageri" References: <1635d77d0802271143u2aeb0b13we310ea1a611afaa8@mail.gmail.com> <6e6841490802271310o3e5976a4gef2cb507087c01b@mail.gmail.com> <1635d77d0802271346g4cf02b8et8bc74d16f6e97e45@mail.gmail.com> <1635d77d0802272002w6aaaa0ect164a64e136b969f5@mail.gmail.com> Date: Thu, 28 Feb 2008 10:12:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 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 15:12:15 -0000 It was not my intention to argue with anybody, I was trying to understand why the packet was blocked and reply to Daniel got bounced, so I posted it in the distro. I got it now, IN packet state doesn't match IN packets, only OUT. Thank you. Vadym ----- Original Message ----- From: "Kian Mohageri" To: "Vadym Chepkov" Cc: Sent: Thursday, February 28, 2008 9:56 AM Subject: Re: floating keep state > On Wed, Feb 27, 2008 at 8:02 PM, Vadym Chepkov wrote: >> set block-policy return >> set state-policy floating >> pass in log quick proto udp from any to 10.10.10.1 port domain keep >> state >> block in log from any to 10.10.11.254 >> >> 22:58:14.296303 rule 0/0(match): pass in on xl1: 10.10.11.254.32772 > >> 10.10.10.1.53: 45616+[|domain] >> 22:58:14.296965 rule 1/0(match): block in on xl0: 10.10.10.1.53 > >> 10.10.11.254.32772: 45616*-[|domain] >> > > States not only have address/port pairs in them (among other things), > but they also have a direction. > > The request packet (coming in on xl1) creates a state that will match > the following: > > 10.10.11.254:32772 ==> 10.10.10.1:53 (IN) > 10.10.10.1:53 ==> 10.10.11.254:32772 (OUT) > > The same packet is filtered again on xl0, but notice it will not match > this state because its direction is now "out". As Daniel said, it's > passed anyway because of the implicit pass rule at the end of your > ruleset (by the way this makes it difficult to troubleshoot problems). > > Server receives packet and replies: > > 10.10.10.1:53 ==> 10.10.11.254:32772 (IN) > > Notice this will not match the state created above (direction is IN, > not OUT), and it will also be blocked by your second rule. > > -Kian > > PS: You'd be smart to listen to Daniel's suggestions as he wrote pf ;)