Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Dec 2019 14:47:03 +0700
From:      Victor Sudakov <vas@sibptus.ru>
To:        freebsd-pf@freebsd.org
Subject:   Re: pf's states
Message-ID:  <20191204074703.GA88680@admin.sibptus.ru>
In-Reply-To: <d26006d1-0b37-d480-07a5-ef6db6e58b24@viklenko.net>
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>

next in thread | previous in thread | raw e-mail | index | archive | help

--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Artem Viklenko via freebsd-pf wrote:

> Had to build test lab....

Thank you for your time.

>=20
> 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.

>=20
> 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.

[dd]

>=20
>   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=20
> created by the same rule #1.
>=20
> 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?

[dd]

>=20
> 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.

>=20
> 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 pfc=
tl
output I provide below:

A brief repetition of what I was doing. I'd be grateful if you replicate it.

1. Interface configuration

hostname=3D"fw.test"
ifconfig_vtnet0=3D"DHCP description Outside"
ifconfig_vtnet1=3D"172.16.1.1/24 description DMZ"
ifconfig_vtnet2=3D"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=
=2E10 to
192.168.10.3 ? I.e. why is this state not overriding the blocking rule 1 ?


--=20
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJd52R3AAoJEA2k8lmbXsY0fikIAJYtdQ4ms9Nhgqh2ZOTS8UTo
jmDGIxCZa2JWKSoQNj88/b6iRngLJKhn6BORRQdeO/nE5gL3y7yYnIiFXacM1PR8
vmB8fpCOM59jz9Adsx8KfYhhrLAjEdlZhYRJ2N0/sgNp5eCWCrGZyhH18e8egWXe
6TR/fhUqClt4ij2wanCbRLhoqCzj3CcR3DsCXxgpjyuAK5BLPRmQlFvJvO4LEMj9
AMQpuXgfqEG796T5Yr3RnC7aZRVhASdEmZo4dVGO2rQLmj3cr2H/Q/KQz0xbz4uG
t4mRqpwRMDo1yQKGNzaZ0t+OMpwpzLSVI3e00tTtY608TjsdhY272mS/hvBXZ6M=
=dzIT
-----END PGP SIGNATURE-----

--y0ulUmNC+osPPQO6--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191204074703.GA88680>