From owner-freebsd-pf@freebsd.org Mon Dec 2 09:37:03 2019 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4A8791CBE8E for ; Mon, 2 Dec 2019 09:37:03 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from mx.als.nnov.ru (mx.als.nnov.ru [95.79.102.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47RKkz6BXnz4s5C for ; Mon, 2 Dec 2019 09:36:59 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from [10.4.1.100] by mx.als.nnov.ru with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1ibi8P-000DL1-Vj for freebsd-pf@freebsd.org; Mon, 02 Dec 2019 12:36:50 +0300 Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> From: Max Message-ID: <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> Date: Mon, 2 Dec 2019 12:36:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191202025642.GA99174@admin.sibptus.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru X-Rspamd-Queue-Id: 47RKkz6BXnz4s5C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of maximos@als.nnov.ru designates 95.79.102.161 as permitted sender) smtp.mailfrom=maximos@als.nnov.ru X-Spamd-Result: default: False [-2.28 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[nnov.ru]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; IP_SCORE(0.00)[country: RU(0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42682, ipnet:95.79.0.0/16, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2019 09:37:03 -0000 Hello. Is this a complete ruleset? What about "pass out..." rules? You should check other rules since you have no "quick" in your listed rules. The last matching rule decides what action is taken. 02.12.2019 5:56, Victor Sudakov пишет: > Dear Colleagues, > > I was asking this question on the freebsd-net mailing list, but I think > it would be better to re-ask it here. > > There is something I cannot understand about pf's notion of state. > > Consider this very simple example with two interfaces: > > =================================== > # DMZ 172.16.1.0/24 > pass in on $dmz > #block in on $dmz from any to 192.168.0.0/16 > > # Inside 192.168.10.0/24 > pass in on $inside > =================================== > > While the "block ..." line is commented out, I can "telnet 172.16.1.10 80" from 192.168.10.3. > But when I uncomment the "block ..." line and restart pf, I cannot do > that any more. Why is that? > > My idea was that the "pass in on $inside" creates state so that return > traffic from 172.16.1.10:80 to 192.168.10.3:xxxxx should be permitted, > but this is not happening so I must be wrong in my understaning how > state works. > >