Date: Wed, 4 Dec 2019 10:55:14 +0200 From: Artem Viklenko <artem@viklenko.net> To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <ce9d31e4-e4b9-bed8-94a7-784c0a059311@viklenko.net> In-Reply-To: <20191204074703.GA88680@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru> <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> <20191202152543.GA16128@admin.sibptus.ru> <c17233fd-e9df-81cc-e015-89f4d5715273@pp.dyndns.biz> <20191203034903.GA33853@admin.sibptus.ru> <aefb012b-970d-9c64-4f5d-31133b2b68ce@pp.dyndns.biz> <20191203094911.GF40372@admin.sibptus.ru> <d26006d1-0b37-d480-07a5-ef6db6e58b24@viklenko.net> <20191204074703.GA88680@admin.sibptus.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ce9d31e4-e4b9-bed8-94a7-784c0a059311>