From owner-freebsd-net@FreeBSD.ORG Wed Feb 1 06:17:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 821ED1065677 for ; Wed, 1 Feb 2012 06:17:28 +0000 (UTC) (envelope-from edward@carrel.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4803D8FC0A for ; Wed, 1 Feb 2012 06:17:27 +0000 (UTC) Received: by iaeo4 with SMTP id o4so1642157iae.13 for ; Tue, 31 Jan 2012 22:17:27 -0800 (PST) Received: by 10.50.153.133 with SMTP id vg5mr5193157igb.8.1328075675353; Tue, 31 Jan 2012 21:54:35 -0800 (PST) Received: from rowlf.sea.carrel.org (dsl231-050-036.sea1.dsl.speakeasy.net. [216.231.50.36]) by mx.google.com with ESMTPS id mr24sm24746047ibb.1.2012.01.31.21.54.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jan 2012 21:54:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Edward Carrel In-Reply-To: <4F1E8EAA.2020905@incore.de> Date: Tue, 31 Jan 2012 21:54:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <643377FE-567E-4E40-8E3A-069F3F004133@carrel.org> References: <4F1E8EAA.2020905@incore.de> To: Andreas Longwitz , freebsd-net@freebsd.org X-Mailer: Apple Mail (2.1251.1) Cc: Subject: Re: pf not seeing inbound packets on netgraph interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 06:17:28 -0000 On Jan 24, 2012, at 2:57 AM, Andreas Longwitz wrote: > Hi Ed, >=20 >> I am running into a roadblock getting PF to filter traffic on >> a Netgraph interface representing an L2TP/IPSec connection. >=20 >> The problem I have is that PF only sees traffic on the outbound >> side of the netgraph interface. >=20 > This happens because the L2TP packets are tagged with an IPSEC-flag = for > later use by ipfw, and this flag is passed to the packets coming from > ng0. Thats done by the netgraph under control of mpd, or better: mpd > does nothing to clear this flag. I was exploring the netgraph sources after sending my original question, = and was developing a suspicion that this is what was going on. =46rom my digging, it didn't look like that mpd would be involved enough = in the communication channel to be able to clear the flag, even if it = wanted to. It would have to be one of the netgraph nodes to do it as the = packet passed by, since mpd only gets informed if a control packet hits = the l2tp note. Or perhaps I am misunderstanding what you mean, or I am = misreading how the data flows around. >=20 > With net.inet.ipsec.filtertunnel=3D1 you can ignore this IPSEC-flag = but > only global for all interfaces in the system. Thats probably not what > you want, especially not for the real hardware interface the > IPSEC-tunnel is going through. It isn't my desired alternative, having already explored that avenue a = while back. I could imagine that I would end up with a severely = complicated pf ruleset even if I could get things to work. >=20 > I think L2TP under control of mpd should work independent of the > existence of an IPSEC-tunnel and therefore clear this flag: >=20 > --- ng_l2tp.c.orig 2010-04-15 14:40:02.000000000 +0200 > +++ ng_l2tp.c 2012-01-23 17:09:41.000000000 +0100 > @@ -752,6 +752,7 @@ > hookpriv_p hpriv =3D NULL; > hook_p hook =3D NULL; > struct mbuf *m; > + struct m_tag *mtag; > u_int16_t tid, sid; > u_int16_t hdr; > u_int16_t ns, nr; > @@ -996,6 +997,11 @@ > ERROUT(0); > } >=20 > + /* Delete an existing ipsec tag */ > + mtag =3D m_tag_find(m, PACKET_TAG_IPSEC_IN_DONE, NULL); > + if (mtag !=3D NULL) > + m_tag_delete(m, mtag); > + > /* Deliver data */ > NG_FWD_NEW_DATA(error, item, hook, m); >=20 > This patch for the l2tp netgraph node does the job and you can use pf = on > the ng0 interface without any restrictions. Very cool. Thanks. I will give this patch a spin, and report back with = my results. A thought that comes to mind; are there other netgraph modules that = would be affected similarly by a packet that comes in with this flag = already set?=20 =46rom what I gathered reading the sources, the same mbuf gets used for = both the L2TP data packet, and the packet encapsulated within -- it = simply trims the header from the mbuf. As such, the mbuf_tags from the = L2TP packet propagate across. This seems like this would not be the most = obvious behavior, at least in some circumstances. I can see perhaps = wanting to propagate things like PF tags from the L2TP packet to the = encapsulated packet across from one interface to another, but I can also = see not wanting to have that happen. If this same sort of thing happens elsewhere, I wonder if this sort of = manipulation wants to happen the moment the packet enters the netgraph = system from a ksocket. Perhaps this will break netgraph behavior = elsewhere that depends on this? I'm also wondering if making the = encapsulated packet even less derivative of the L2TP packet would make = unexpected behavior like what I was observing less likely. Again, I'm = not familiar enough with all the netgraph modules to know what might = depend on this behavior, or if there are historical or functional = reasons to keep the behavior as it is. Thanks, Ed Carrel=