From owner-freebsd-pf@freebsd.org Thu Dec 5 05:33:34 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 9ACEA1BBC7F for ; Thu, 5 Dec 2019 05:33:34 +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 47T4Bh0kD8z3Jsh for ; Thu, 5 Dec 2019 05:33:31 +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 1icjlY-0009HD-F6 for freebsd-pf@freebsd.org; Thu, 05 Dec 2019 08:33:28 +0300 Subject: Re: pf's states To: freebsd-pf@freebsd.org References: <20191202025642.GA99174@admin.sibptus.ru> <90c1b342-b88a-a9bc-d475-4e6cd027f25c@als.nnov.ru> <20191202134047.GA14183@admin.sibptus.ru> <0c189ef5-61a3-209b-84a1-9982fde94073@als.nnov.ru> <20191204140000.GA96563@admin.sibptus.ru> <20191205042435.GA19962@admin.sibptus.ru> From: Max Message-ID: Date: Thu, 5 Dec 2019 08:33:28 +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: <20191205042435.GA19962@admin.sibptus.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru X-Rspamd-Queue-Id: 47T4Bh0kD8z3Jsh 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.99)[-0.988,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: Thu, 05 Dec 2019 05:33:34 -0000 No. You have no block rules on $inside (no rules at all in this case). PF uses default pass with no states. I think we should consider the traffic flow from the firewall's point of view. It has incoming and outgoing flows. That's all. Transitional flow is just a combination of incoming and outgoing. If we have incoming packets from some source ip (straight flow) then reversed packets will flow to that source ip. When we send packets to some destination ip (staright flow) the reversed will be arriving from that destination ip. No matter if we use one interface or two. So, in the case of transitional connection it will be: 1. recieving packet from src to dst (incoming) 2. creating state src-dst allowing to pass replies TO src (and straignt flow from src) 3. routing 4. sending packet from src to dst (outgoing) 5. creating state dst-src allowing to pass replies FROM dst (and straight flow to dst) > 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:43:38, expires in 00:00:10, 2498:2498 pkts, 209832:209832 bytes, rule 3 > id: 000000005de764a4 creatorid: 4e14336a > all icmp 192.168.10.3:33794 -> 172.16.1.10:33794 0:0 > age 00:43:38, expires in 00:00:10, 2498:2498 pkts, 209832:209832 bytes, rule 2 > id: 000000005de764a5 creatorid: 4e14336a > root@fw:~ # > > I begin to see two identical (?) floating states. I call them identical because > both denote the direction of traffic "192.168.10.3 -> 172.16.1.10". There is not > a state with (reversed) key "172.16.1.10 -> 192.168.10.3", but the return > traffic is now somehow magically passed. I'm mystified again. They are distinguish. "<-" means incoming flow, "->" means outgoing flow. 05.12.2019 7:24, Victor Sudakov пишет: > Victor Sudakov wrote: >> Max wrote: > [dd] > >>> Or you can create "pass out on $dmz..." rule. >> Yeah, that sounds great. The ping responses begin to arrive at 192.168.10.3! >> Victory! > You know what! If I create a "pass out on $dmz..." rule, no rules on > $inside are necessary any more. pfctl shows only *one* state, but this time > it is sufficient: > > 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: 15 Packets: 0 Bytes: 0 States: 0 ] > [ Inserted: uid 0 pid 1262 State Creations: 0 ] > @1 block return in on vtnet1 inet from any to 192.168.0.0/16 > [ Evaluations: 1 Packets: 1 Bytes: 84 States: 0 ] > [ Inserted: uid 0 pid 1262 State Creations: 0 ] > @2 pass out on vtnet1 all flags S/SA keep state > [ Evaluations: 1 Packets: 0 Bytes: 0 States: 0 ] > [ Inserted: uid 0 pid 1262 State Creations: 0 ] > root@fw:~ # > > root@fw:~ # pfctl -vvs states > No ALTQ support in kernel > ALTQ related functions disabled > all icmp 192.168.10.3:63234 -> 172.16.1.10:63234 0:0 > age 00:00:11, expires in 00:00:09, 11:11 pkts, 924:924 bytes, rule 2 > id: 000000005de88142 creatorid: 68441fab > root@fw:~ # > > Now 192.168.10.3 can ping 172.16.1.10 and receive echo replies, 172.16.1.10 > cannot ping 192.168.10.3. > > Don't you think there is something non-trivial or even incorrect about the > way states are evaluated? >