From owner-freebsd-pf@freebsd.org Wed Dec 4 08:55:24 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 8989C1CE05A for ; Wed, 4 Dec 2019 08:55:24 +0000 (UTC) (envelope-from artem@viklenko.net) Received: from alf.viklenko.net (alf.viklenko.net [IPv6:2001:470:71:d72::61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.viklenko.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47SXk329K3z4bQv for ; Wed, 4 Dec 2019 08:55:22 +0000 (UTC) (envelope-from artem@viklenko.net) Received: from [10.0.31.12] (ua1.etadirect.net [91.198.140.16] (may be forged)) (authenticated bits=0) by alf.viklenko.net (8.15.2/8.15.2) with ESMTPSA id xB48tFkX007421 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Dec 2019 10:55:20 +0200 (EET) (envelope-from artem@viklenko.net) 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> <20191203034903.GA33853@admin.sibptus.ru> <20191203094911.GF40372@admin.sibptus.ru> <20191204074703.GA88680@admin.sibptus.ru> From: Artem Viklenko Organization: Art&Co. Message-ID: Date: Wed, 4 Dec 2019 10:55:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: <20191204074703.GA88680@admin.sibptus.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (alf.viklenko.net [192.168.32.61]); Wed, 04 Dec 2019 10:55:20 +0200 (EET) X-Rspamd-Queue-Id: 47SXk329K3z4bQv X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.64 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[viklenko.net:s=alf-mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[viklenko.net:+]; DMARC_POLICY_ALLOW(-0.50)[viklenko.net,reject]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.64)[ipnet: 2001:470::/32(-4.64), asn: 6939(-3.53), country: US(-0.05)]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; 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: Wed, 04 Dec 2019 08:55:24 -0000 On 04.12.19 09:47, Victor Sudakov wrote: > Artem Viklenko via freebsd-pf wrote: > >> Had to build test lab.... > > Thank you for your time. > >> >> I still not 100% sure about state-policy - can't check it now. >> But it definitelly can influence on the final result. > > Let's stick to the default floating state-policy for now. No need to make > the lab more complicated. > >> >> Simple ruleset: > > Once you have invested your time to build the lab, could you please > reproduce my ruleset exactly (I'll repeat it below)? Unlike yours, my > ruleset has *all* rules bound to interfaces. It would be also very nice of > you to use the same IP addresses so that we did not have to translate the > addresses mentally. Actually, no. Seems I've provided enougth examples. > > [dd] > >> >> Traffic coming in the system was inspected by pf >> rules and first state was created. Then traffic going out to destination >> via another interface was inspected by pf again and second state was >> created by the same rule #1. >> >> ICMP replies going in reverse direction pass due to these states. > > Why would you need two states to pass the replies, that is the > question. If the rule is floating, why is one rule not enough? > Not I need - this is how PF works. > [dd] > >> >> This is because by default pf allows traffic but not create states. >> You can start pf with empty ruleset and see no states while traffic >> passing firewall. > > No doubt about it. But I was not talking about the complete absense of > states. Please see below. > >> >> So then traffic came back it was blocked by last matched rule with >> keyword in which is rule #2 in this case. > > No, in my case *one* state is being created. The question is why this one > available state is not enough to pass return traffic? Please peruse the pfctl > output I provide below: > > A brief repetition of what I was doing. I'd be grateful if you replicate it. Similar case - from the traffic point of view - already in my post with explanations. > > 1. Interface configuration > > hostname="fw.test" > ifconfig_vtnet0="DHCP description Outside" > ifconfig_vtnet1="172.16.1.1/24 description DMZ" > ifconfig_vtnet2="192.168.10.1/24 description Inside" > > 2. Ping configuration > > Pinging 172.16.1.10 (dmz host) from 192.168.10.3 (inside host). > > 3. Rules > > root@fw:~ # pfctl -vvs rules > No ALTQ support in kernel > ALTQ related functions disabled > @0 pass in on vtnet1 all flags S/SA keep state > [ Evaluations: 9596 Packets: 1 Bytes: 84 States: 0 ] > [ Inserted: uid 0 pid 1343 State Creations: 1 ] > @1 block drop in on vtnet1 inet from any to 192.168.0.0/16 > [ Evaluations: 2955 Packets: 2954 Bytes: 248136 States: 0 ] > [ Inserted: uid 0 pid 1343 State Creations: 0 ] > @2 pass in on vtnet2 all flags S/SA keep state > [ Evaluations: 6641 Packets: 2955 Bytes: 248220 States: 1 ] > [ Inserted: uid 0 pid 1343 State Creations: 2 ] > root@fw:~ # > > > 4. State while pinging: > > root@fw:~ # pfctl -vvs states > No ALTQ support in kernel > ALTQ related functions disabled > all icmp 172.16.1.10:33794 <- 192.168.10.3:33794 0:0 > age 00:51:57, expires in 00:00:10, 2970:0 pkts, 249480:0 bytes, rule 2 > id: 000000005de756c8 creatorid: 9da41898 > root@fw:~ # > > > 5. Question: > > We see that a floating state "172.16.1.10:33794 <- 192.168.10.3:33794" has been > created by rule 2. Why is this state not passing ICMP replies from 172.16.1.10 to > 192.168.10.3 ? I.e. why is this state not overriding the blocking rule 1 ? > > -- Regards!