From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 09:33:28 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29B95106566C; Tue, 17 Apr 2012 09:33:28 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D155E8FC0A; Tue, 17 Apr 2012 09:33:27 +0000 (UTC) Received: by iahk25 with SMTP id k25so11368379iah.13 for ; Tue, 17 Apr 2012 02:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZD6TJjUWtOR46StqoXbkWB6p4/P8Q1PR/vp2hy7QQbs=; b=gJhOXJB3geyIy2mG1x+s3zb2IL3/3qMRPRbaVNpZiLOElaVuvYg8rjb5rXMr+AcEeD mCg6as5Q+YdKznS1ZxkmHmryedy26IpTUSYZifV3EweY4he+B2pQte1km9jsJyjPIh6f 8BC+xiRcZ9ZjVb2Rh49pBEOH2tW0Mr4/ORO8Qaw+GuD94RqamMjSqjK4jMdQ/EZvucXX M0QtjGcQrU2XRFtVd6SDVdANComRJF+i+vD34RnImrZXWaTuus5CaPtuIGy0oPYg+VUY SDK2Mu5RlzI8DBVFiJiB04wRLbr6m/wgOeIJifdj2U3PkWJSuzGDLCEDkSdsEs/30oS7 a62Q== MIME-Version: 1.0 Received: by 10.50.203.74 with SMTP id ko10mr1869032igc.7.1334655207372; Tue, 17 Apr 2012 02:33:27 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.243.65 with HTTP; Tue, 17 Apr 2012 02:33:27 -0700 (PDT) In-Reply-To: <20120417084608.GA99119@glebius.int.ru> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> <20120417081406.GA93887@glebius.int.ru> <20120417084608.GA99119@glebius.int.ru> Date: Tue, 17 Apr 2012 11:33:27 +0200 X-Google-Sender-Auth: SRx6cy_8qFzKf09FeZczYMHylOg Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 09:33:28 -0000 2012/4/17 Gleb Smirnoff : > On Tue, Apr 17, 2012 at 10:38:31AM +0200, Ermal Lu?i wrote: > E> 2012/4/17 Gleb Smirnoff : > E> > > E> > In this case crash or freeze is fixed, but still packet is dropped. = Example > E> > of such rule: > E> > > E> > pass in on igb0 fastroute proto tcp from any to $localip > E> > > E> > Anyway, dropping packets is much better than crashing. > E> > > E> > E> Actually after some coffee :) i think its better marking the packet > E> with M_SKIP_FIREWALL since > E> it has already taken its decision on this packet. > E> > E> The simloop consumers seem to be just facilities of how things work > E> from what i can see. > E> > E> So just delivering the packet by sending skipping the firewalls seems > E> more sensibile! > E> > E> Though the persistent case for the tags should be revisited since it > E> may fix some other issues with pf(4) tags, and some others. > > We can make the assignment like: > > if (ifp->if_flags & IFF_LOOPBACK) > =A0 =A0 =A0 =A0m->m_flags |=3D M_SKIP_FIREWALL; Yeah the protection seems sensible enough, probably needs some more testing first. I will try to do some asap. The issue is that pf(4) with state keeping is not designed to see a looping packet. Also the pf(4) route-to/reply-to logic is not meant to loop packet back but deliver them to final configured destination. Hence the skip firewall. The only problem i might see is when running more than one firewall together but still there are other issues when you do that at pfil(9) level. Also, if_simloop is not meant for packet leaving the host so that should be safe no? > > Because only loopback interface is special: processing its ifp->if_output= () > leads to re-entering ip_input(). > > I'm afraid that if we mark all pf-routed packets as M_SKIP_FIREWALL, that > can lead to a case when packet is routed by pf processing on input hook, = and > then it skips processing the output hook, and that can lead to state > not being updated and session stuck. > > Still, I think that pf tag deserves MTAG_PERSISTENT. That would keep us > in-line with OpenBSD, since they store pf information right in the pkthdr= , > and I don't think that they erase it anywhere until mbuf is freed. Do agree > > -- > Totus tuus, Glebius. --=20 Ermal