From owner-freebsd-pf@freebsd.org Mon Dec 2 19:19:09 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 218BE1B4321 for ; Mon, 2 Dec 2019 19:19:09 +0000 (UTC) (envelope-from freebsd-database@pp.dyndns.biz) Received: from keymaster.local (ns1.xn--wesstrm-f1a.se [IPv6:2a00:d880:5:1b9::8526]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "keymaster.pp.dyndns.biz", Issuer "keymaster.pp.dyndns.biz" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47RZfg6r5qz4F8q for ; Mon, 2 Dec 2019 19:19:07 +0000 (UTC) (envelope-from freebsd-database@pp.dyndns.biz) Received: from [192.168.69.69] ([192.168.69.69]) by keymaster.local (8.15.2/8.15.2) with ESMTP id xB2JIwpI078522 for ; Mon, 2 Dec 2019 20:18:59 +0100 (CET) (envelope-from freebsd-database@pp.dyndns.biz) Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> From: =?UTF-8?Q?Morgan_Wesstr=c3=b6m?= Message-ID: Date: Mon, 2 Dec 2019 20:18:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191202152543.GA16128@admin.sibptus.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47RZfg6r5qz4F8q X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-database@pp.dyndns.biz has no SPF policy when checking 2a00:d880:5:1b9::8526) smtp.mailfrom=freebsd-database@pp.dyndns.biz X-Spamd-Result: default: False [1.72 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.72)[-0.717,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-0.03)[asn: 198203(-0.18), country: NL(0.02)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.27)[0.272,0]; HFILTER_HELO_IP_A(1.00)[keymaster.local]; R_SPF_NA(0.00)[]; HFILTER_HELO_NORES_A_OR_MX(0.30)[keymaster.local]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:198203, ipnet:2a00:d880::/32, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_NA(0.00)[pp.dyndns.biz]; 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 19:19:09 -0000 >>> =================================== >>> # 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. >> >> Rule 1 does not match this packet >> Rule 3 matches said packet, action is PASS The pass directive creates a state when only SYN is set out of SYN and ACK as per the manual page. It does NOT create a state when both SYN and ACK is set simultaneously as in your initial reply from the telnet server. Afaik a pass rule only creates state on the interface it monitors. I did not recreate your setup to check this though. But this is what should happen: With rule 2 remarked: - Your initial telnet SYN will create state on $inside through rule 3. - There should be no state created on $dmz. - Your SYN+ACK reply and further replies will be passed by pf's default pass behaviour on $dmz. With rule 2 active: - Your initial telnet SYN will create state on $inside through rule 3. - There should be no state created on $dmz. - Your SYN+ACK reply and further replies will be blocked by rule 2 since they match this rule and there are no states on $dmz to take precedence. My advice is to create ingoing and outgoing pass rules on both interfaces and to specify the state/flags combination even if they're the default. This way you will create states on both interfaces as you expect and additionally not run into nasty surprises if the default behaviour is changed in a future version of pf. pass in on $dmz flags S/SA keep state pass out on $dmz flags S/SA keep state pass in on $inside flags S/SA keep state pass out on $inside flags S/SA keep state /Morgan