Date: Mon, 2 Dec 2019 15:59:21 +0100 From: Kajetan Staszkiewicz <vegeta@tuxpowered.net> To: freebsd-pf@freebsd.org Subject: Re: pf's states Message-ID: <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> In-Reply-To: <20191202025642.GA99174@admin.sibptus.ru> References: <20191202025642.GA99174@admin.sibptus.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dROpFXdnOibHxjLkOM25A2EYr9q12AHUI Content-Type: multipart/mixed; boundary="dYya6WJAZm50C03ztUDVdrmjkzbO9oXFa"; protected-headers="v1" From: Kajetan Staszkiewicz <vegeta@tuxpowered.net> To: freebsd-pf@freebsd.org Message-ID: <7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e@tuxpowered.net> Subject: Re: pf's states References: <20191202025642.GA99174@admin.sibptus.ru> In-Reply-To: <20191202025642.GA99174@admin.sibptus.ru> --dYya6WJAZm50C03ztUDVdrmjkzbO9oXFa Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 02.12.19 03:56, Victor Sudakov wrote: > Dear Colleagues, >=20 > I was asking this question on the freebsd-net mailing list, but I think= > it would be better to re-ask it here. >=20 > There is something I cannot understand about pf's notion of state.=20 >=20 > Consider this very simple example with two interfaces: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > # DMZ 172.16.1.0/24 > pass in on $dmz > #block in on $dmz from any to 192.168.0.0/16 >=20 > # Inside 192.168.10.0/24 > pass in on $inside > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > While the "block ..." line is commented out, I can "telnet 172.16.1.10 = 80" from 192.168.10.3. For initial SYN of TCP connection from 192.168.10.3 to 172.16.1.10 rule evaluation looks like below. Returning SYN+ACK and all further packets will be matched against states. It is not possible with pf to skip matching to existing states. It's done in code before ruleset evaluation.= Your initial SYN is "in" on $inside and "out" on $dmz, correct? Rule 1 does not match this packet Rule 3 matches said packet, action is PASS > But when I uncomment the "block ..." line and restart pf, I cannot do > that any more. Why is that? Then it looks like this: Rule 1 does not match this packet Rule 2 does not match this packet Rule 3 matches said packet, action is PASS There should be no difference. Are you sure you're talking about connection from $inside to $dmz and that variables are not swapped? And are you sure you're making a new TCP connection and not just talking about the old one being terminated? Restarting pf (service pf restart) will terminate existing states. All existing tcp connections will either immediately reset or timeout, depending on other conditions. In most cases you don't want to restart pf but only apply new ruleset. Unless you want to restart. That depends on your security considerations because reloading new ruleset keeps existing sessions so even if you remove them from firewall, users connected before that over, let's say ssh, will still remain connected. > 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 It should be like this, yes. > so I must be wrong in my understaning how > state works. Please remember that pf on a router creates 2 states: one before routing, one after. Existing states and ruleset are evaluated twice. First state will be "in on $iface1" and the other "out on $iface2". Both states might be created by same rule if you don't provide "on $iface" in rule and only operate on IP addresses. The last thing I would like to point out is that your firewall lacks final blocking rule. Designing firewalls by mixing passes and blocks is generally a bad idea. It's way safer to provide a single blocking rule for all traffic on all interfaces and then allow only some subsets of traffic. --=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' --dYya6WJAZm50C03ztUDVdrmjkzbO9oXFa-- --dROpFXdnOibHxjLkOM25A2EYr9q12AHUI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSOEQZObv2B8mf0JbnjtFCvbXs6FAUCXeUmyQAKCRDjtFCvbXs6 FJ5HAJ9oBmKfZhimqxtVWBGVBsQcIhTzUQCg435oHpYJr5k/JRYwbdahlRXkOgQ= =nx+s -----END PGP SIGNATURE----- --dROpFXdnOibHxjLkOM25A2EYr9q12AHUI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7a5b77d9-29d2-4fb4-b82c-3e6a194baf6e>