kern/102647: Using pf stateful rules for inet6 fails
for connections originating from the firewall itself to a service running
on thesame box
Max Laier
max at love2party.net
Fri Sep 1 19:30:24 UTC 2006
The following reply was made to PR kern/102647; it has been noted by GNATS.
From: Max Laier <max at love2party.net>
To: freebsd-pf at freebsd.org
Cc: SUZUKI Shinsuke <suz at freebsd.org>,
steinex at nognu.de,
freebsd-gnats-submit at freebsd.org
Subject: Re: kern/102647: Using pf stateful rules for inet6 fails =?iso-8859-6?q?for=09connections_originating_from_the_firewall_itself_to_a?=
=?iso-8859-6?q?_service=09running_on_thesame?= box
Date: Fri, 1 Sep 2006 21:22:45 +0200
--nextPart8266172.WiydWlPtKC
Content-Type: text/plain;
charset="iso-8859-6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday 30 August 2006 03:13, SUZUKI Shinsuke wrote:
> Hi,
>
> >>>>> On Tue, 29 Aug 2006 16:37:23 GMT
> >>>>> steinex at nognu.de(Frank Steinborn) said:
> >
> > Thanks to Max Laier for examining this, I'll just paste him:
> >
> > Using pf stateful rules for inet6 fails for connections originating
> > from the firewall itself to a service running on the same box.=20
> > Culprit seems to be interface selection in inet6 (switching between
> > the interface that has the address configured and lo0).
> >
> > tcpdump on pflog0 shows that the initial SYN is coming from bge0 (See=20
> > below for ruleset used). The reply then comes via lo0 and matches the=
=20
> > state (if state-policy is floating). The third packet (again via=20
> > bge0) then does no longer match the state - however: =20
> > >How-To-Repeat:
> >
> > Use this ruleset:
> >
> > pass quick on lo0 all
> > pass quick on bge0 inet all
> > block drop log all
> > pass in log-all on bge0 inet6 proto tcp from any to 3000::1 port =3D
> > ssh flags S/SA keep state
> >
> > Then try to open an inet6-connection to a service running on the
> > firewall itself from the firewall itself.
>
> Could you please try the attached patch for kernel?
>
> Using this patch, PF regards the initial SYN (and the third packet) is
> coming from lo0, instead of bge0. (There was a similar bug-report
> regarding PF for looped-back IPv6 packet, and this patch fixed the
> problem)
>
> If it seems okay from the PF's point of view, I'll commit it to
> -current.
Thinking about this for a bit we might want to use the patch below=20
instead. i.e. do the fixup locally in the pfil wrapper instead. This=20
way other filters don't break if they have adapted to the new world=20
order.
Thoughts? Please test and report back, either way.
=2D-=20
/"\ Best regards, | mlaier at freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier at EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Index: pf_ioctl.c
=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=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
RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf_ioctl.c,v
retrieving revision 1.25
diff -u -r1.25 pf_ioctl.c
=2D-- pf_ioctl.c 21 Jul 2006 09:48:13 -0000 1.25
+++ pf_ioctl.c 1 Sep 2006 19:19:49 -0000
@@ -3442,7 +3442,8 @@
*/
int chk;
=20
=2D chk =3D pf_test6(PF_IN, ifp, m, NULL, inp);
+ chk =3D pf_test6(PF_IN, (*m)->m_flags & M_LOOP ? &loif[0] : ifp, m,
+ NULL, inp);
if (chk && *m) {
m_freem(*m);
*m =3D NULL;
--nextPart8266172.WiydWlPtKC
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQBE+IiNXyyEoT62BG0RAkzdAJ4ihqjT9VOrWXhRRO1//iZpP1ogvwCfYzRs
4StEPzlMg/h1KOUA2tpGKA4=
=gyfj
-----END PGP SIGNATURE-----
--nextPart8266172.WiydWlPtKC--
More information about the freebsd-pf
mailing list