From nobody@FreeBSD.org  Tue Aug 29 16:37:24 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4A11A16A4E0
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 29 Aug 2006 16:37:24 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 13BDB43D46
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 29 Aug 2006 16:37:24 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k7TGbNt5002410
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 29 Aug 2006 16:37:23 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k7TGbNxd002409;
	Tue, 29 Aug 2006 16:37:23 GMT
	(envelope-from nobody)
Message-Id: <200608291637.k7TGbNxd002409@www.freebsd.org>
Date: Tue, 29 Aug 2006 16:37:23 GMT
From: Frank Steinborn <steinex@nognu.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Using pf stateful rules for inet6 fails for connections originating from the firewall itself to a service running on thesame box
X-Send-Pr-Version: www-2.3

>Number:         102647
>Category:       kern
>Synopsis:       Using pf stateful rules for inet6 fails for connections originating from the firewall itself to a service running on thesame box
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-pf
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 29 16:40:16 GMT 2006
>Closed-Date:    Sat Sep 09 00:51:11 GMT 2006
>Last-Modified:  Sat Sep 09 00:51:11 GMT 2006
>Originator:     Frank Steinborn
>Release:        6.1-RELEASE-p3
>Organization:
>Environment:
FreeBSD shodan.nognu.de 6.1-RELEASE-p3 FreeBSD 6.1-RELEASE-p3 #0: Sun Jul 23 22:12:17 CEST 2006     steinex@shodan.nognu.de:/usr/home/steinex/obj/usr/src/sys/SHODAN  i386
>Description:
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.  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 below
for ruleset used).  The reply then comes via lo0 and matches the state (if
state-policy is floating).  The third packet (again via bge0) then does no
longer match the state - however:

17:51:17.594100 rule 3/0(match): pass in on bge0: 3000::1.54335 > 3000::1.22:
S 3551126931:3551126931(0) win 65535 <mss 1440,nop,wscale 1,nop,nop,timestamp
2188256 0,sackOK,eol>

17:51:17.594150 rule 3/0(match): pass out on lo0: 3000::1.22 > 3000::1.54335:
S 3700289867:3700289867(0) ack 3551126932 win 65535 <mss 1440,nop,wscale
1,nop,nop,timestamp 2188256 2188256,sackOK,eol>

17:51:17.594157 rule 2/0(match): block in on bge0: 3000::1.22 > 3000::1.54335:
S 3700289867:3700289867(0) ack 3551126932 win 65535 <mss 1440,nop,wscale
1,nop,nop,timestamp 2188256 2188256,sackOK,eol>

>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 = 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.
>Fix:

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-pf 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Tue Aug 29 22:40:14 UTC 2006 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=102647 

From: SUZUKI Shinsuke <suz@freebsd.org>
To: steinex@nognu.de, freebsd-pf@FreeBSD.org
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/102647: Using pf stateful rules for inet6 fails for	connections originating from the firewall itself to a service	running on thesame box
Date: Wed, 30 Aug 2006 10:13:32 +0900

 --Multipart_Wed_Aug_30_10:13:32_2006-1
 Content-Type: text/plain; charset=US-ASCII
 
 Hi,
 
 >>>>> On Tue, 29 Aug 2006 16:37:23 GMT
 >>>>> steinex@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.  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 below for ruleset used).  The reply then comes via lo0 and matches the state (if state-policy is floating).  The third packet (again via bge0) then does no longer match the state - however:
 
 > >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 = 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.
 
 Thanks,
 ----
 SUZUKI, Shinsuke @ KAME Project
 
 
 
 --Multipart_Wed_Aug_30_10:13:32_2006-1
 Content-Type: text/plain; charset=US-ASCII
 
 Index: ip6_input.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/netinet6/ip6_input.c,v
 retrieving revision 1.88
 diff -u -u -r1.88 ip6_input.c
 --- ip6_input.c	4 Aug 2006 21:27:39 -0000	1.88
 +++ ip6_input.c	30 Aug 2006 00:49:48 -0000
 @@ -407,7 +407,18 @@
  	if (!PFIL_HOOKED(&inet6_pfil_hook))
  		goto passin;
  
 -	if (pfil_run_hooks(&inet6_pfil_hook, &m, m->m_pkthdr.rcvif, PFIL_IN, NULL))
 +	/* 
 +	 * When the packet loops back from the host itself, m_pkthdr.rcvif points
 +	 * to the lo0 in case of IPv4.  Whereas in case of IPv6, it points to the
 +	 * interface with the destination IPv6 address, to support IPv6 scoped 
 +	 * address.
 +	 * To keep the legacy assumption in filter configuration (looped-back
 +	 * packet comes from lo0), explicitly passes lo0 as the incoming interface
 +	 * of a looped-back packet.
 +	 */
 +	if (pfil_run_hooks(&inet6_pfil_hook, &m,
 +	    m->m_flags & M_LOOP ? &loif[0] : m->m_pkthdr.rcvif,
 +	    PFIL_IN, NULL))
  		return;
  	if (m == NULL)			/* consumed by filter */
  		return;
 
 --Multipart_Wed_Aug_30_10:13:32_2006-1--

From: Max Laier <max@love2party.net>
To: freebsd-pf@freebsd.org
Cc: SUZUKI Shinsuke <suz@freebsd.org>,
 steinex@nognu.de,
 freebsd-gnats-submit@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: Wed, 30 Aug 2006 13:39:34 +0200

 --nextPart1732840.TuzD54aPQf
 Content-Type: text/plain;
   charset="iso-8859-6"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline
 
 SUZUKI-san,
 
 since you are looking at this already could I interest you in a related=20
 problem?
 
 On Wednesday 30 August 2006 03:13, SUZUKI Shinsuke wrote:
 > Hi,
 >
 > >>>>> On Tue, 29 Aug 2006 16:37:23 GMT
 > >>>>> steinex@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.
 
 Your patch looks good for the problem reported, there is - however -=20
 another problem that maybe related.  The bottom line is that packets to=20
 or from local addresses never show up on bpf as they are not processed by=20
 lo0's input/output routines.  Do you have any idea how to address this?
 
 =2D-=20
 /"\  Best regards,                      | mlaier@freebsd.org
 \ /  Max Laier                          | ICQ #67774661
  X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
 / \  ASCII Ribbon Campaign              | Against HTML Mail and News
 
 --nextPart1732840.TuzD54aPQf
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.5 (FreeBSD)
 
 iD8DBQBE9Xj+XyyEoT62BG0RAimwAJ4s0elYgCMVPOUEtzk8jjS/hSQmLACfakuq
 ueTEDz/pV8klfRGbVhNiS1U=
 =C21O
 -----END PGP SIGNATURE-----
 
 --nextPart1732840.TuzD54aPQf--

From: SUZUKI Shinsuke <suz@freebsd.org>
To: max@love2party.net
Cc: freebsd-pf@freebsd.org, suz@freebsd.org, steinex@nognu.de,
	freebsd-gnats-submit@freebsd.org
Subject: Re: kern/102647: Using pf stateful rules for inet6 fails
    for	connections originating from the firewall itself to a service	running
    on thesame box
Date: Thu, 31 Aug 2006 15:47:13 +0900

 Hi, Max.
 
 >>>>> On Wed, 30 Aug 2006 13:39:34 +0200
 >>>>> max@love2party.net(Max Laier)  said:
 
 > another problem that maybe related.  The bottom line is that packets
 > to or from local addresses never show up on bpf as they are not
 > processed by lo0's input/output routines.  Do you have any idea how
 > to address this?
 
 It is a spec (bug?) of if_simloop() (net/if_loop.c), not regarding
 this problem.
 
 - The BPF of the physical interface, instead of lo0, detects the packet.
 	% ping6 fe80::20c:29ff:fe54:6378%lnc2
 	16 bytes from fe80::20c:29ff:fe54:6378%lnc2, icmp_seq=0 hlim=64 time=2.857 ms
 
 	% tcpdump -X -ni lnc2
 	3a:40:fe:80:00:00 > 60:00:00:00:00:10 Null Information, send seq 1, rcv seq 6, Flags [Command], length 42
 	0x0000:  0000 020c 29ff fe54 6378 fe80 0000 0000  ....)..Tcx......
 	0x0010:  0000 020c 29ff fe54 6378 8000 3c25 0bfe  ....)..Tcx..<%..
 	0x0020:  0000 44f6 81de 0004 5806                 ..D.....X.
 	
 	3a:40:fe:80:00:00 > 60:00:00:00:00:10 Null Information, send seq 1, rcv seq 6, Flags [Command], length 42
         0x0000:  0000 020c 29ff fe54 6378 fe80 0000 0000  ....)..Tcx......
         0x0010:  0000 020c 29ff fe54 6378 8100 3b25 0bfe  ....)..Tcx..;%..
         0x0020:  0000 44f6 81de 0004 5806                 ..D.....X.
     
 - if_simloop() just passes the received mbuf to the BPF of the
   physical interface in case of IPv6.  (please see the following code)
    
 	if (ifp->if_bpf) {
 		if (ifp->if_bpf->bif_dlt == DLT_NULL) {
 			u_int32_t af1 = af;	/* XXX beware sizeof(af) != 4 */
 			bpf_mtap2(ifp->if_bpf, &af1, sizeof(af1), m);
 			<= this one is called in case of IPv4,
 			   since ifp=lo0
 		} else
 			bpf_mtap(ifp->if_bpf, m);
 			<= this one is normally called in case of IPv6,
 			   since ifp=physical I/F and physical I/F's DLT is
 			   normally DLT_EN10MB
 	}
 
 - However, due to a lack of correct layer2 header information, the BPF
   cannot display the packet correctly. (A dummy padding can partly
   solve the problem.  But it would be problematic in terms of BPF
   filtering based on layer-2 information...)
   
 
 Thanks,
 ----
 SUZUKI, Shinsuke @ KAME Project
 

From: Max Laier <max@love2party.net>
To: freebsd-pf@freebsd.org
Cc: SUZUKI Shinsuke <suz@freebsd.org>,
 steinex@nognu.de,
 freebsd-gnats-submit@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@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@freebsd.org
 \ /  Max Laier                          | ICQ #67774661
  X   http://pf4freebsd.love2party.net/  | mlaier@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--
State-Changed-From-To: open->feedback 
State-Changed-By: suz 
State-Changed-When: Tue Sep 5 03:54:33 UTC 2006 
State-Changed-Why:  
patch is proposed by Max Laier 

http://www.freebsd.org/cgi/query-pr.cgi?pr=102647 

From: SUZUKI Shinsuke <suz@freebsd.org>
To: max@love2party.net
Cc: freebsd-pf@freebsd.org,
	suz@freebsd.org,
	steinex@nognu.de,
	freebsd-gnats-submit@freebsd.org
Subject: Re: kern/102647: Using pf stateful rules for inet6 fails for	connections originating from the firewall itself to a service	running on thesame box
Date: Tue, 05 Sep 2006 12:53:26 +0900

 Hi,
 
 >>>>> On Fri, 1 Sep 2006 21:22:45 +0200
 >>>>> max@love2party.net(Max Laier)  said:
 
 > Thinking about this for a bit we might want to use the patch below 
 > instead.  i.e. do the fixup locally in the pfil wrapper instead.  This 
 > way other filters don't break if they have adapted to the new world 
 > order.
 > 
 > Thoughts?  Please test and report back, either way.
 
 I'm fine with your patch. (it is preferable to add a comment about
 this hack, though)
 
 After the PR originator confirmed the fix, could you please commit it?
 
 Thanks,
 ----
 SUZUKI, Shinsuke @ KAME Project
 
 > Index: pf_ioctl.c
 > ===================================================================
 > 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
 > --- 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;
 >  
 > -	chk = pf_test6(PF_IN, ifp, m, NULL, inp);
 > +	chk = pf_test6(PF_IN, (*m)->m_flags & M_LOOP ? &loif[0] : ifp, m,
 > +	    NULL, inp);
 >  	if (chk && *m) {
 >  		m_freem(*m);
 >  		*m = NULL;

From: Frank Steinborn <steinex@nognu.de>
To: SUZUKI Shinsuke <suz@freebsd.org>
Cc: max@love2party.net, freebsd-pf@freebsd.org,
	freebsd-gnats-submit@freebsd.org
Subject: Re: kern/102647: Using pf stateful rules for inet6 fails for	connections originating from the firewall itself to a service	running on thesame box
Date: Wed, 6 Sep 2006 15:49:22 +0200

 SUZUKI Shinsuke wrote:
 > Hi,
 > 
 > >>>>> On Fri, 1 Sep 2006 21:22:45 +0200
 > >>>>> max@love2party.net(Max Laier)  said:
 > 
 > > Thinking about this for a bit we might want to use the patch below 
 > > instead.  i.e. do the fixup locally in the pfil wrapper instead.  This 
 > > way other filters don't break if they have adapted to the new world 
 > > order.
 > > 
 > > Thoughts?  Please test and report back, either way.
 > 
 > I'm fine with your patch. (it is preferable to add a comment about
 > this hack, though)
 > 
 > After the PR originator confirmed the fix, could you please commit it?
 > 
 > Thanks,
 > ----
 > SUZUKI, Shinsuke @ KAME Project
 
 I'm not sure if my first confirmation about the fix came through, so
 I'll resend to get sure.
 
 Well, as I said - the patch works fine here, I'm fine with it too.
 Would be nice to see in in -STABLE soon.
 
 Many thanks!
 
 Frank
State-Changed-From-To: feedback->patched 
State-Changed-By: mlaier 
State-Changed-When: Wed Sep 6 17:20:03 UTC 2006 
State-Changed-Why:  
Committed to HEAD, MFC in three days.  Thanks tracking this down. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=102647 
State-Changed-From-To: patched->closed 
State-Changed-By: mlaier 
State-Changed-When: Sat Sep 9 00:50:45 UTC 2006 
State-Changed-Why:  
Committed, thanks. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=102647 
>Unformatted:
