From owner-freebsd-pf@FreeBSD.ORG Sun Apr 15 11:10:03 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4D584106564A for ; Sun, 15 Apr 2012 11:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 316888FC0C for ; Sun, 15 Apr 2012 11:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3FBA3c1034334 for ; Sun, 15 Apr 2012 11:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3FBA3Fr034331; Sun, 15 Apr 2012 11:10:03 GMT (envelope-from gnats) Date: Sun, 15 Apr 2012 11:10:03 GMT Message-Id: <201204151110.q3FBA3Fr034331@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Gleb Smirnoff Cc: Subject: 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 Reply-To: Gleb Smirnoff 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: Sun, 15 Apr 2012 11:10:03 -0000 The following reply was made to PR kern/164402; it has been noted by GNATS. From: Gleb Smirnoff To: "Eugene M. Zheganin" Cc: bug-followup@FreeBSD.org Subject: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives Date: Sun, 15 Apr 2012 15:07:56 +0400 Hi, I have a vague suspicion on what is happening. Your description of the problem looks like if a packet processing in the kernel has entered an endless loop. Looking at pf_route() I see such possibility. From OpenBSD we have this protection against endless looping: if ((*m)->m_pkthdr.pf.routed++ > 3) { m0 = *m; *m = NULL; goto bad; } In our code this transforms to: if (pd->pf_mtag->routed++ > 3) { m0 = *m; *m = NULL; goto bad; } The root difference between storing the tag on mbuf and on pfdesc is that we lose pfdesc, and thus the tag, when we enter pf_test() recursively. And pf_route() does this recursion: if (oifp != ifp) { if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) { goto bad; .... -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Sun Apr 15 11:51:29 2012 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CCE21065670; Sun, 15 Apr 2012 11:51:29 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id DB3158FC21; Sun, 15 Apr 2012 11:51:25 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q3FBpOWf081021; Sun, 15 Apr 2012 15:51:24 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q3FBpOow081020; Sun, 15 Apr 2012 15:51:24 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 15 Apr 2012 15:51:24 +0400 From: Gleb Smirnoff To: freebsd-pf@FreeBSD.org Message-ID: <20120415115124.GO9391@FreeBSD.org> References: <201204151110.q3FBA3Fr034331@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201204151110.q3FBA3Fr034331@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: bug-followup@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: Sun, 15 Apr 2012 11:51:29 -0000 On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote: T> I have a vague suspicion on what is happening. Your description of T> the problem looks like if a packet processing in the kernel has entered T> an endless loop. T> T> Looking at pf_route() I see such possibility. From OpenBSD we have T> this protection against endless looping: T> T> if ((*m)->m_pkthdr.pf.routed++ > 3) { T> m0 = *m; T> *m = NULL; T> goto bad; T> } T> T> In our code this transforms to: T> T> if (pd->pf_mtag->routed++ > 3) { T> m0 = *m; T> *m = NULL; T> goto bad; T> } T> T> The root difference between storing the tag on mbuf and on pfdesc T> is that we lose pfdesc, and thus the tag, when we enter pf_test() T> recursively. And pf_route() does this recursion: T> T> if (oifp != ifp) { T> if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) { T> goto bad; T> .... On second look I see that my suspicion may not be true. In the beginning of pf_test() we do pf_get_mtag() which preserves already present tag if there is one. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Sun Apr 15 11:53:13 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63C25106564A; Sun, 15 Apr 2012 11:53:13 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 377DC8FC0A; Sun, 15 Apr 2012 11:53:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3FBrDA8084841; Sun, 15 Apr 2012 11:53:13 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3FBrDrx084837; Sun, 15 Apr 2012 11:53:13 GMT (envelope-from glebius) Date: Sun, 15 Apr 2012 11:53:13 GMT Message-Id: <201204151153.q3FBrDrx084837@freefall.freebsd.org> To: balustefan@gmail.com, glebius@FreeBSD.org, freebsd-pf@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/166411: [pf] simply enabling pf makes udpxy not to work 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: Sun, 15 Apr 2012 11:53:13 -0000 Synopsis: [pf] simply enabling pf makes udpxy not to work State-Changed-From-To: open->closed State-Changed-By: glebius State-Changed-When: Sun Apr 15 11:52:16 UTC 2012 State-Changed-Why: pf(4) dropping packets with IP options by default isn't a bug, but a (annoying) feature. http://www.freebsd.org/cgi/query-pr.cgi?pr=166411 From owner-freebsd-pf@FreeBSD.ORG Sun Apr 15 12:00:21 2012 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A15C7106567B for ; Sun, 15 Apr 2012 12:00:21 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 73F508FC12 for ; Sun, 15 Apr 2012 12:00:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3FC0LCx085163 for ; Sun, 15 Apr 2012 12:00:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3FC0LT5085161; Sun, 15 Apr 2012 12:00:21 GMT (envelope-from gnats) Date: Sun, 15 Apr 2012 12:00:21 GMT Message-Id: <201204151200.q3FC0LT5085161@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Gleb Smirnoff Cc: 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 Reply-To: Gleb Smirnoff 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: Sun, 15 Apr 2012 12:00:21 -0000 The following reply was made to PR kern/164402; it has been noted by GNATS. From: Gleb Smirnoff To: freebsd-pf@FreeBSD.org Cc: bug-followup@FreeBSD.org Subject: Re: kern/164402: [pf] pf crashes with a particular set of rules when first matching packet arrives Date: Sun, 15 Apr 2012 15:51:24 +0400 On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote: T> I have a vague suspicion on what is happening. Your description of T> the problem looks like if a packet processing in the kernel has entered T> an endless loop. T> T> Looking at pf_route() I see such possibility. From OpenBSD we have T> this protection against endless looping: T> T> if ((*m)->m_pkthdr.pf.routed++ > 3) { T> m0 = *m; T> *m = NULL; T> goto bad; T> } T> T> In our code this transforms to: T> T> if (pd->pf_mtag->routed++ > 3) { T> m0 = *m; T> *m = NULL; T> goto bad; T> } T> T> The root difference between storing the tag on mbuf and on pfdesc T> is that we lose pfdesc, and thus the tag, when we enter pf_test() T> recursively. And pf_route() does this recursion: T> T> if (oifp != ifp) { T> if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) { T> goto bad; T> .... On second look I see that my suspicion may not be true. In the beginning of pf_test() we do pf_get_mtag() which preserves already present tag if there is one. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Mon Apr 16 11:07:24 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 B911B1065678 for ; Mon, 16 Apr 2012 11:07:24 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A42E48FC1D for ; Mon, 16 Apr 2012 11:07:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3GB7OvC022476 for ; Mon, 16 Apr 2012 11:07:24 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3GB7NZa022474 for freebsd-pf@FreeBSD.org; Mon, 16 Apr 2012 11:07:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Apr 2012 11:07:23 GMT Message-Id: <201204161107.q3GB7NZa022474@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org 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: Mon, 16 Apr 2012 11:07:24 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/166336 pf [pf] kern.securelevel 3 +pf reload o kern/165315 pf [pf] States never cleared in PF with DEVICE_POLLING o kern/164402 pf [pf] pf crashes with a particular set of rules when fi o kern/164271 pf [pf] not working pf nat on FreeBSD 9.0 [regression] o kern/163208 pf [pf] PF state key linking mismatch o kern/160370 pf [pf] Incorrect pfctl check of pf.conf o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 49 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Apr 16 18:59:51 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 28886106566C for ; Mon, 16 Apr 2012 18:59:51 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 936BE8FC1A for ; Mon, 16 Apr 2012 18:59:50 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q3GIxnZW093518 for ; Mon, 16 Apr 2012 22:59:49 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q3GIxnkQ093517 for freebsd-pf@freebsd.org; Mon, 16 Apr 2012 22:59:49 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 16 Apr 2012 22:59:49 +0400 From: Gleb Smirnoff To: freebsd-pf@FreeBSD.org Message-ID: <20120416185949.GC92286@FreeBSD.org> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201204151200.q3FC0LT5085161@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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: Mon, 16 Apr 2012 18:59:51 -0000 On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote: T> On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote: T> T> I have a vague suspicion on what is happening. Your description of T> T> the problem looks like if a packet processing in the kernel has entered T> T> an endless loop. T> T> T> T> Looking at pf_route() I see such possibility. From OpenBSD we have T> T> this protection against endless looping: T> T> T> T> if ((*m)->m_pkthdr.pf.routed++ > 3) { T> T> m0 = *m; T> T> *m = NULL; T> T> goto bad; T> T> } T> T> T> T> In our code this transforms to: T> T> T> T> if (pd->pf_mtag->routed++ > 3) { T> T> m0 = *m; T> T> *m = NULL; T> T> goto bad; T> T> } T> T> T> T> The root difference between storing the tag on mbuf and on pfdesc T> T> is that we lose pfdesc, and thus the tag, when we enter pf_test() T> T> recursively. And pf_route() does this recursion: T> T> T> T> if (oifp != ifp) { T> T> if (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) { T> T> goto bad; T> T> .... T> T> On second look I see that my suspicion may not be true. In the T> beginning of pf_test() we do pf_get_mtag() which preserves already T> present tag if there is one. Further investigation showed that problem exist when route applied ends in lo0, and packet passes to if_simloop(). There all mtags are stripped from the mbuf, including the pf mtag. Then packet is again processed by ip_input() again entering pf(4), if it again matches a routing rule, then we got an endless loop. We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 08:06:16 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32B6F1065677; Tue, 17 Apr 2012 08:06:16 +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 D21468FC1B; Tue, 17 Apr 2012 08:06:15 +0000 (UTC) Received: by iahk25 with SMTP id k25so11239503iah.13 for ; Tue, 17 Apr 2012 01:06:15 -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=vTdjz2jBwwr30XM/F9AEgugEjLJRWbHU8IC7nYwaLEo=; b=UI3rc12VZEOZ8OcI0mFN780f71csElahuWiENmBRdUK/hxQx8JknrpBUVSbvaGEOCL kcAaN9/FXustHva+RcWgFhw18sPYJoyTqIP/2KmpHoRCjQfyUjKi/OzhutJ+/Ew7IzqR BwX+VGOmC7fhUDQCJALyEo4n/7dh3J6X6jLl9dvlyJzq4BwGq9EM/qnlq4vC5s6XD1xH z/l8ZOxV3korFJg2EbuRm7rDCqoqAvb9EK7QqQVylYLrhP2dWIvdHNHZpL/bsn0WxdEl AzhaIOji52GiYvLDKzTwHZC+PIolqH4Ye6Yjy7nIC0ArG2eZNmPhLRoHuucbHhT8PiSm 2dKQ== MIME-Version: 1.0 Received: by 10.50.203.74 with SMTP id ko10mr1649932igc.7.1334649975247; Tue, 17 Apr 2012 01:06:15 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.243.65 with HTTP; Tue, 17 Apr 2012 01:06:15 -0700 (PDT) In-Reply-To: <20120416185949.GC92286@FreeBSD.org> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> Date: Tue, 17 Apr 2012 10:06:15 +0200 X-Google-Sender-Auth: ItLEHrXp10sdESigQQkH7ZCXsOw 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 08:06:16 -0000 2012/4/16 Gleb Smirnoff : > On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote: > T> =A0On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote: > T> =A0T> =A0 =A0I have a vague suspicion on what is happening. Your descr= iption of > T> =A0T> =A0the problem looks like if a packet processing in the kernel h= as entered > T> =A0T> =A0an endless loop. > T> =A0T> > T> =A0T> =A0 =A0Looking at pf_route() I see such possibility. From OpenBS= D we have > T> =A0T> =A0this protection against endless looping: > T> =A0T> > T> =A0T> =A0 =A0 =A0 =A0 =A0if ((*m)->m_pkthdr.pf.routed++ > 3) { > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m0 =3D *m; > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*m =3D NULL; > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto bad; > T> =A0T> =A0 =A0 =A0 =A0 =A0} > T> =A0T> > T> =A0T> =A0In our code this transforms to: > T> =A0T> > T> =A0T> =A0 =A0 =A0 =A0 =A0if (pd->pf_mtag->routed++ > 3) { > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m0 =3D *m; > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*m =3D NULL; > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto bad; > T> =A0T> =A0 =A0 =A0 =A0 =A0} > T> =A0T> > T> =A0T> =A0The root difference between storing the tag on mbuf and on pf= desc > T> =A0T> =A0is that we lose pfdesc, and thus the tag, when we enter pf_te= st() > T> =A0T> =A0recursively. And pf_route() does this recursion: > T> =A0T> > T> =A0T> =A0 =A0 =A0 =A0 =A0if (oifp !=3D ifp) { > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (pf_test(PF_OUT, ifp, &m0,= NULL) !=3D PF_PASS) { > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto bad; > T> =A0T> =A0 =A0 =A0 =A0 =A0.... > T> > T> =A0On second look I see that my suspicion may not be true. In the > T> =A0beginning of pf_test() we do pf_get_mtag() which preserves already > T> =A0present tag if there is one. > > Further investigation showed that problem exist when route applied > ends in lo0, and packet passes to if_simloop(). There all mtags are > stripped from the mbuf, including the pf mtag. Then packet is again > processed by ip_input() again entering pf(4), if it again matches > a routing rule, then we got an endless loop. > > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id. > That seems like the best fix for this case. > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" --=20 Ermal From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 08:14:09 2012 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0416C106564A; Tue, 17 Apr 2012 08:14:09 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9EC8FC12; Tue, 17 Apr 2012 08:14:08 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q3H8E6jQ098838; Tue, 17 Apr 2012 12:14:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q3H8E6ab098837; Tue, 17 Apr 2012 12:14:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 17 Apr 2012 12:14:06 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20120417081406.GA93887@glebius.int.ru> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 08:14:09 -0000 On Tue, Apr 17, 2012 at 10:06:15AM +0200, Ermal Lu?i wrote: E> 2012/4/16 Gleb Smirnoff : E> > On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote: E> > T> šOn Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote: E> > T> šT> š šI have a vague suspicion on what is happening. Your description of E> > T> šT> šthe problem looks like if a packet processing in the kernel has entered E> > T> šT> šan endless loop. E> > T> šT> E> > T> šT> š šLooking at pf_route() I see such possibility. From OpenBSD we have E> > T> šT> šthis protection against endless looping: E> > T> šT> E> > T> šT> š š š š šif ((*m)->m_pkthdr.pf.routed++ > 3) { E> > T> šT> š š š š š š š š šm0 = *m; E> > T> šT> š š š š š š š š š*m = NULL; E> > T> šT> š š š š š š š š šgoto bad; E> > T> šT> š š š š š} E> > T> šT> E> > T> šT> šIn our code this transforms to: E> > T> šT> E> > T> šT> š š š š šif (pd->pf_mtag->routed++ > 3) { E> > T> šT> š š š š š š š š šm0 = *m; E> > T> šT> š š š š š š š š š*m = NULL; E> > T> šT> š š š š š š š š šgoto bad; E> > T> šT> š š š š š} E> > T> šT> E> > T> šT> šThe root difference between storing the tag on mbuf and on pfdesc E> > T> šT> šis that we lose pfdesc, and thus the tag, when we enter pf_test() E> > T> šT> šrecursively. And pf_route() does this recursion: E> > T> šT> E> > T> šT> š š š š šif (oifp != ifp) { E> > T> šT> š š š š š š š š šif (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) { E> > T> šT> š š š š š š š š š š š š šgoto bad; E> > T> šT> š š š š š.... E> > T> E> > T> šOn second look I see that my suspicion may not be true. In the E> > T> šbeginning of pf_test() we do pf_get_mtag() which preserves already E> > T> špresent tag if there is one. E> > E> > Further investigation showed that problem exist when route applied E> > ends in lo0, and packet passes to if_simloop(). There all mtags are E> > stripped from the mbuf, including the pf mtag. Then packet is again E> > processed by ip_input() again entering pf(4), if it again matches E> > a routing rule, then we got an endless loop. E> > E> > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id. E> E> That seems like the best fix for this case. In this case crash or freeze is fixed, but still packet is dropped. Example of such rule: pass in on igb0 fastroute proto tcp from any to $localip Anyway, dropping packets is much better than crashing. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 08:38:32 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 629AB106566B; Tue, 17 Apr 2012 08:38:32 +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 17F9E8FC22; Tue, 17 Apr 2012 08:38:32 +0000 (UTC) Received: by iahk25 with SMTP id k25so11287758iah.13 for ; Tue, 17 Apr 2012 01:38:31 -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=kgIs0/IBW3an/l9B20oqfqRzaJZ66IxvNgQFbCoEreY=; b=Pps23QXYFah9XVwFvM7EMIKeZ3CRtwr2fTAXPc0KhHsbk0ZV+JJeMJUVQ/Chq6Km4L EY++PKpiByv41MDB3zLbQwbMCiZMfwj8U8Tgr/MO01pVBj2iymqsw6yeZK3e/sGuqUyI c4Qmf0u+VkxrkZjFPLbd6aonU04Et6fTgs0Amwp3CIO3Oval/J5ats63afR8MHiVlwnf jesaNkNOWO4zw4317YFEPPUY/cB+bnL8hKepbGCuIq0GFDyPw9BYbw0B+LHtxAeV6eWP a2bmPrYWWAMOmv9hrrNJ9dkT2jZFTW4TmscpHNf3cGKYc09KPujwHJIH7agcL+NWXeKP 7+6A== MIME-Version: 1.0 Received: by 10.50.41.168 with SMTP id g8mr8282736igl.17.1334651911767; Tue, 17 Apr 2012 01:38:31 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.243.65 with HTTP; Tue, 17 Apr 2012 01:38:31 -0700 (PDT) In-Reply-To: <20120417081406.GA93887@glebius.int.ru> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> <20120417081406.GA93887@glebius.int.ru> Date: Tue, 17 Apr 2012 10:38:31 +0200 X-Google-Sender-Auth: H2tZtDpQ7X1xpWKbcYvEuTvWsJs 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 08:38:32 -0000 2012/4/17 Gleb Smirnoff : > On Tue, Apr 17, 2012 at 10:06:15AM +0200, Ermal Lu?i wrote: > E> 2012/4/16 Gleb Smirnoff : > E> > On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote: > E> > T> =A0On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote: > E> > T> =A0T> =A0 =A0I have a vague suspicion on what is happening. Your = description of > E> > T> =A0T> =A0the problem looks like if a packet processing in the ker= nel has entered > E> > T> =A0T> =A0an endless loop. > E> > T> =A0T> > E> > T> =A0T> =A0 =A0Looking at pf_route() I see such possibility. From O= penBSD we have > E> > T> =A0T> =A0this protection against endless looping: > E> > T> =A0T> > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0if ((*m)->m_pkthdr.pf.routed++ > 3) { > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m0 =3D *m; > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*m =3D NULL; > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto bad; > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0} > E> > T> =A0T> > E> > T> =A0T> =A0In our code this transforms to: > E> > T> =A0T> > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0if (pd->pf_mtag->routed++ > 3) { > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m0 =3D *m; > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*m =3D NULL; > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto bad; > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0} > E> > T> =A0T> > E> > T> =A0T> =A0The root difference between storing the tag on mbuf and = on pfdesc > E> > T> =A0T> =A0is that we lose pfdesc, and thus the tag, when we enter = pf_test() > E> > T> =A0T> =A0recursively. And pf_route() does this recursion: > E> > T> =A0T> > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0if (oifp !=3D ifp) { > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (pf_test(PF_OUT, ifp,= &m0, NULL) !=3D PF_PASS) { > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto bad= ; > E> > T> =A0T> =A0 =A0 =A0 =A0 =A0.... > E> > T> > E> > T> =A0On second look I see that my suspicion may not be true. In the > E> > T> =A0beginning of pf_test() we do pf_get_mtag() which preserves alr= eady > E> > T> =A0present tag if there is one. > E> > > E> > Further investigation showed that problem exist when route applied > E> > ends in lo0, and packet passes to if_simloop(). There all mtags are > E> > stripped from the mbuf, including the pf mtag. Then packet is again > E> > processed by ip_input() again entering pf(4), if it again matches > E> > a routing rule, then we got an endless loop. > E> > > E> > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id. > E> > E> That seems like the best fix for this case. > > In this case crash or freeze is fixed, but still packet is dropped. Examp= le > of such rule: > > pass in on igb0 fastroute proto tcp from any to $localip > > Anyway, dropping packets is much better than crashing. > Actually after some coffee :) i think its better marking the packet with M_SKIP_FIREWALL since it has already taken its decision on this packet. The simloop consumers seem to be just facilities of how things work from what i can see. So just delivering the packet by sending skipping the firewalls seems more sensibile! Though the persistent case for the tags should be revisited since it may fix some other issues with pf(4) tags, and some others. > -- > Totus tuus, Glebius. --=20 Ermal From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 08:42:52 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B54B2106564A; Tue, 17 Apr 2012 08:42:52 +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 694A98FC12; Tue, 17 Apr 2012 08:42:52 +0000 (UTC) Received: by iahk25 with SMTP id k25so11294274iah.13 for ; Tue, 17 Apr 2012 01:42:52 -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=uEu8X/DYTl3FNngzYEwQxhc2qUhG8tqp/o2jMcqIjsc=; b=ZXJYsa+W3eUBjrGFvR28va1mwWuP5OOfbj8pIPSJ4EgvYFj6JdRyVgbYl9hNT6LtGc qjdYxhOS1nCjhA5+wiK3FYknLHNWlDd45dM7khPqJ4KkRCqF3DsrFFfKfkeel0G+ulxW dwb3m6qBs/SScM8fHuvdc86h1i05RDegNy8ztP6fTo/Nm14WIVWQL7frpw57UURR5MIg UdvAtI28d1gsx9zkS+80D97qmwltthsIfDa4lD/iJy16jsZba6YD2h7/vbB+t0u9WdBk DiG5z4uJgShJWyXP9rtTX5ONXZgZvlZsNTD9Q17BcCYaubS/soAnFxJASF9d2CkFTz6U 5uGQ== MIME-Version: 1.0 Received: by 10.50.156.170 with SMTP id wf10mr8395271igb.7.1334652172106; Tue, 17 Apr 2012 01:42:52 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.243.65 with HTTP; Tue, 17 Apr 2012 01:42:52 -0700 (PDT) In-Reply-To: References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> <20120417081406.GA93887@glebius.int.ru> Date: Tue, 17 Apr 2012 10:42:52 +0200 X-Google-Sender-Auth: i7mmT5JdDi-WRPDRsu0bCe56BUA 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 08:42:52 -0000 On Tue, Apr 17, 2012 at 10:38 AM, Ermal Lu=E7i wrote: > 2012/4/17 Gleb Smirnoff : >> On Tue, Apr 17, 2012 at 10:06:15AM +0200, Ermal Lu?i wrote: >> E> 2012/4/16 Gleb Smirnoff : >> E> > On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote: >> E> > T> =A0On Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote= : >> E> > T> =A0T> =A0 =A0I have a vague suspicion on what is happening. Your= description of >> E> > T> =A0T> =A0the problem looks like if a packet processing in the ke= rnel has entered >> E> > T> =A0T> =A0an endless loop. >> E> > T> =A0T> >> E> > T> =A0T> =A0 =A0Looking at pf_route() I see such possibility. From = OpenBSD we have >> E> > T> =A0T> =A0this protection against endless looping: >> E> > T> =A0T> >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0if ((*m)->m_pkthdr.pf.routed++ > 3) { >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m0 =3D *m; >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*m =3D NULL; >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto bad; >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0} >> E> > T> =A0T> >> E> > T> =A0T> =A0In our code this transforms to: >> E> > T> =A0T> >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0if (pd->pf_mtag->routed++ > 3) { >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0m0 =3D *m; >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*m =3D NULL; >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto bad; >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0} >> E> > T> =A0T> >> E> > T> =A0T> =A0The root difference between storing the tag on mbuf and= on pfdesc >> E> > T> =A0T> =A0is that we lose pfdesc, and thus the tag, when we enter= pf_test() >> E> > T> =A0T> =A0recursively. And pf_route() does this recursion: >> E> > T> =A0T> >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0if (oifp !=3D ifp) { >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (pf_test(PF_OUT, ifp= , &m0, NULL) !=3D PF_PASS) { >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto ba= d; >> E> > T> =A0T> =A0 =A0 =A0 =A0 =A0.... >> E> > T> >> E> > T> =A0On second look I see that my suspicion may not be true. In th= e >> E> > T> =A0beginning of pf_test() we do pf_get_mtag() which preserves al= ready >> E> > T> =A0present tag if there is one. >> E> > >> E> > Further investigation showed that problem exist when route applied >> E> > ends in lo0, and packet passes to if_simloop(). There all mtags are >> E> > stripped from the mbuf, including the pf mtag. Then packet is again >> E> > processed by ip_input() again entering pf(4), if it again matches >> E> > a routing rule, then we got an endless loop. >> E> > >> E> > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id= . >> E> >> E> That seems like the best fix for this case. >> >> In this case crash or freeze is fixed, but still packet is dropped. Exam= ple >> of such rule: >> >> pass in on igb0 fastroute proto tcp from any to $localip >> >> Anyway, dropping packets is much better than crashing. To be more explicit, this breaks functionality. Since as i said the firewall has already taken descision and the state keeping for sure will drop this matching tcp packets. You will not see it for other protos that do not have the state transition like tcp though your statistics will be wrong. This is not justifible and its better to crash :) Though as i said the skip firewall flag seems more sensible. >> > > Actually after some coffee :) i think its better marking the packet > with M_SKIP_FIREWALL since > it has already taken its decision on this packet. > > The simloop consumers seem to be just facilities of how things work > from what i can see. > > So just delivering the packet by sending skipping the firewalls seems > more sensibile! > > Though the persistent case for the tags should be revisited since it > may fix some other issues with pf(4) tags, and some others. > >> -- >> Totus tuus, Glebius. > > > > -- > Ermal --=20 Ermal From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 08:46:10 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 38F501065689; Tue, 17 Apr 2012 08:46:10 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id AB6DC8FC1C; Tue, 17 Apr 2012 08:46:09 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q3H8k8pi099215; Tue, 17 Apr 2012 12:46:08 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q3H8k844099214; Tue, 17 Apr 2012 12:46:08 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 17 Apr 2012 12:46:08 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20120417084608.GA99119@glebius.int.ru> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> <20120417081406.GA93887@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 08:46:10 -0000 On Tue, Apr 17, 2012 at 10:38:31AM +0200, Ermal Lu?i wrote: E> 2012/4/17 Gleb Smirnoff : E> > On Tue, Apr 17, 2012 at 10:06:15AM +0200, Ermal Lu?i wrote: E> > E> 2012/4/16 Gleb Smirnoff : E> > E> > On Sun, Apr 15, 2012 at 12:00:21PM +0000, Gleb Smirnoff wrote: E> > E> > T> šOn Sun, Apr 15, 2012 at 11:10:03AM +0000, Gleb Smirnoff wrote: E> > E> > T> šT> š šI have a vague suspicion on what is happening. Your description of E> > E> > T> šT> šthe problem looks like if a packet processing in the kernel has entered E> > E> > T> šT> šan endless loop. E> > E> > T> šT> E> > E> > T> šT> š šLooking at pf_route() I see such possibility. From OpenBSD we have E> > E> > T> šT> šthis protection against endless looping: E> > E> > T> šT> E> > E> > T> šT> š š š š šif ((*m)->m_pkthdr.pf.routed++ > 3) { E> > E> > T> šT> š š š š š š š š šm0 = *m; E> > E> > T> šT> š š š š š š š š š*m = NULL; E> > E> > T> šT> š š š š š š š š šgoto bad; E> > E> > T> šT> š š š š š} E> > E> > T> šT> E> > E> > T> šT> šIn our code this transforms to: E> > E> > T> šT> E> > E> > T> šT> š š š š šif (pd->pf_mtag->routed++ > 3) { E> > E> > T> šT> š š š š š š š š šm0 = *m; E> > E> > T> šT> š š š š š š š š š*m = NULL; E> > E> > T> šT> š š š š š š š š šgoto bad; E> > E> > T> šT> š š š š š} E> > E> > T> šT> E> > E> > T> šT> šThe root difference between storing the tag on mbuf and on pfdesc E> > E> > T> šT> šis that we lose pfdesc, and thus the tag, when we enter pf_test() E> > E> > T> šT> šrecursively. And pf_route() does this recursion: E> > E> > T> šT> E> > E> > T> šT> š š š š šif (oifp != ifp) { E> > E> > T> šT> š š š š š š š š šif (pf_test(PF_OUT, ifp, &m0, NULL) != PF_PASS) { E> > E> > T> šT> š š š š š š š š š š š š šgoto bad; E> > E> > T> šT> š š š š š.... E> > E> > T> E> > E> > T> šOn second look I see that my suspicion may not be true. In the E> > E> > T> šbeginning of pf_test() we do pf_get_mtag() which preserves already E> > E> > T> špresent tag if there is one. E> > E> > E> > E> > Further investigation showed that problem exist when route applied E> > E> > ends in lo0, and packet passes to if_simloop(). There all mtags are E> > E> > stripped from the mbuf, including the pf mtag. Then packet is again E> > E> > processed by ip_input() again entering pf(4), if it again matches E> > E> > a routing rule, then we got an endless loop. E> > E> > E> > E> > We can try to fix this applying MTAG_PERSISTENT to the pf(4) tag id. E> > E> E> > E> That seems like the best fix for this case. 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) m->m_flags |= M_SKIP_FIREWALL; 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. -- Totus tuus, Glebius. 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 From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 09:48:26 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 EC764106566B; Tue, 17 Apr 2012 09:48:26 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 61F388FC08; Tue, 17 Apr 2012 09:48:26 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q3H9mPKj099970; Tue, 17 Apr 2012 13:48:25 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q3H9mPbD099969; Tue, 17 Apr 2012 13:48:25 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 17 Apr 2012 13:48:25 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20120417094825.GC99119@glebius.int.ru> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> <20120417081406.GA93887@glebius.int.ru> <20120417084608.GA99119@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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:48:27 -0000 Replying on only on paragrapg, everything else agreed. On Tue, Apr 17, 2012 at 11:33:27AM +0200, Ermal Lu?i wrote: E> The only problem i might see is when running more than one firewall E> together but still there are other issues when you do that at pfil(9) E> level. Well, playing with two firewalls was never safe and clear, there always be edge cases in such setups. E> Also, if_simloop is not meant for packet leaving the host so that E> should be safe no? Shouldn't live, but it still enters pfil(9) and there one or other firewall can again bounce it in any direction. Probable M_SKIP_FIREWALL is good idea. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 14:02:07 2012 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A82C81065672; Tue, 17 Apr 2012 14:02:07 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 1ED168FC17; Tue, 17 Apr 2012 14:02:06 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q3HE25cC002185; Tue, 17 Apr 2012 18:02:05 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q3HE25AN002184; Tue, 17 Apr 2012 18:02:05 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 17 Apr 2012 18:02:05 +0400 From: Gleb Smirnoff To: Ermal Lu?i Message-ID: <20120417140205.GA2140@glebius.int.ru> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> <20120417081406.GA93887@glebius.int.ru> <20120417084608.GA99119@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20120417084608.GA99119@glebius.int.ru> User-Agent: Mutt/1.5.21 (2010-09-15) 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 14:02:07 -0000 On Tue, Apr 17, 2012 at 12:46:08PM +0400, Gleb Smirnoff wrote: T> We can make the assignment like: T> T> if (ifp->if_flags & IFF_LOOPBACK) T> m->m_flags |= M_SKIP_FIREWALL; I've tested this plus MTAG_PERSISTENT on pf tags, and it looks like this works. At least for the "fastroute" case, which was defnitely not working before. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 16:32:36 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 87CE7106564A; Tue, 17 Apr 2012 16:32:36 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE868FC12; Tue, 17 Apr 2012 16:32:36 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id C806E25D39FD; Tue, 17 Apr 2012 16:32:34 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id D11AABE50B2; Tue, 17 Apr 2012 16:32:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 6VQx3HbanZCj; Tue, 17 Apr 2012 16:32:32 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id BC40BBE50B0; Tue, 17 Apr 2012 16:32:32 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120417094825.GC99119@glebius.int.ru> Date: Tue, 17 Apr 2012 16:32:31 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5CA2DD90-145C-44F2-AD66-2DBCE8989C2A@lists.zabbadoz.net> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> <20120417081406.GA93887@glebius.int.ru> <20120417084608.GA99119@glebius.int.ru> <20120417094825.GC99119@glebius.int.ru> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1084) Cc: Ermal Lu?i , 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 16:32:36 -0000 On 17. Apr 2012, at 09:48 , Gleb Smirnoff wrote: > Replying on only on paragrapg, everything else agreed. >=20 > On Tue, Apr 17, 2012 at 11:33:27AM +0200, Ermal Lu?i wrote: > E> The only problem i might see is when running more than one firewall > E> together but still there are other issues when you do that at = pfil(9) > E> level. >=20 > Well, playing with two firewalls was never safe and clear, there = always > be edge cases in such setups. A lot of people have used ipfw to filter L2 MAC addresses etc and pf for = everything else in the past. So certainly is not an edge case. --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 16:33:36 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 8A434106566B; Tue, 17 Apr 2012 16:33:36 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 011DF8FC0C; Tue, 17 Apr 2012 16:33:35 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q3HGXYku003275; Tue, 17 Apr 2012 20:33:34 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q3HGXYrp003274; Tue, 17 Apr 2012 20:33:34 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 17 Apr 2012 20:33:34 +0400 From: Gleb Smirnoff To: "Bjoern A. Zeeb" Message-ID: <20120417163334.GB2140@glebius.int.ru> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> <20120417081406.GA93887@glebius.int.ru> <20120417084608.GA99119@glebius.int.ru> <20120417094825.GC99119@glebius.int.ru> <5CA2DD90-145C-44F2-AD66-2DBCE8989C2A@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <5CA2DD90-145C-44F2-AD66-2DBCE8989C2A@lists.zabbadoz.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ermal Lu?i , 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 16:33:36 -0000 On Tue, Apr 17, 2012 at 04:32:31PM +0000, Bjoern A. Zeeb wrote: B> > On Tue, Apr 17, 2012 at 11:33:27AM +0200, Ermal Lu?i wrote: B> > E> The only problem i might see is when running more than one firewall B> > E> together but still there are other issues when you do that at pfil(9) B> > E> level. B> > B> > Well, playing with two firewalls was never safe and clear, there always B> > be edge cases in such setups. B> B> A lot of people have used ipfw to filter L2 MAC addresses etc and pf for everything else in the past. So certainly is not an edge case. Enabling two firewalls isn't an edge case, but when two firewalls enabled there are numerouse possibilities to do evil misconfigurations. -- Totus tuus, Glebius. From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 19:19:51 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 A59D71065741; Tue, 17 Apr 2012 19:19:51 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 42DC28FC1B; Tue, 17 Apr 2012 19:19:51 +0000 (UTC) Received: by yhgm50 with SMTP id m50so3955085yhg.13 for ; Tue, 17 Apr 2012 12:19:50 -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=GLKSktxCmuDmZLBiVPtydRYjM2UJVZRQFLjqClgmm5Y=; b=AYiiA4uPkDDpJNyp5iGjozZr0wmUDSiyDghtdr3hcCfNElAQ+lC4R7Yyem/AXH1evT PcJNbXZtDMhXE23spVPEo/GgkvLLZRY7pa2A0eRymke+TPm0tAZK/gz3mbvYw/cx5LSP BicF8y6/swL3hDphFuLMM6sLxGO/fUhg8CnbInWP+ZLw0iS+1i7JgZH9tUH2E3cYHG26 f99C5RlR4/wOyktAeLtvEM7zWnSwOuwV05hMhMbu0Q1NJype3c+EnZgBHo1HCYceWoH/ SraQUxYsBAo/RpAI7gKJhh//+mlt8r+WsxIx1rS2sbNQYe99+EtIPnJbWLKR05ZImw4S 1xXQ== MIME-Version: 1.0 Received: by 10.50.237.65 with SMTP id va1mr10672406igc.17.1334690390501; Tue, 17 Apr 2012 12:19:50 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.243.65 with HTTP; Tue, 17 Apr 2012 12:19:50 -0700 (PDT) In-Reply-To: <5CA2DD90-145C-44F2-AD66-2DBCE8989C2A@lists.zabbadoz.net> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> <20120417081406.GA93887@glebius.int.ru> <20120417084608.GA99119@glebius.int.ru> <20120417094825.GC99119@glebius.int.ru> <5CA2DD90-145C-44F2-AD66-2DBCE8989C2A@lists.zabbadoz.net> Date: Tue, 17 Apr 2012 21:19:50 +0200 X-Google-Sender-Auth: CEl3MB0sTFOxJje5R0_h5LAOn_g Message-ID: From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: "Bjoern A. Zeeb" 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 19:19:51 -0000 On Tue, Apr 17, 2012 at 6:32 PM, Bjoern A. Zeeb wrote: > > On 17. Apr 2012, at 09:48 , Gleb Smirnoff wrote: > >> =A0Replying on only on paragrapg, everything else agreed. >> >> On Tue, Apr 17, 2012 at 11:33:27AM +0200, Ermal Lu?i wrote: >> E> The only problem i might see is when running more than one firewall >> E> together but still there are other issues when you do that at pfil(9) >> E> level. >> >> Well, playing with two firewalls was never safe and clear, there always >> be edge cases in such setups. > > A lot of people have used ipfw to filter L2 MAC addresses etc and pf for = everything else in the past. =A0So certainly is not an edge case. I know that since pfSense uses that extenively. But this does not break this case. It only affects packets going back at ip level. with ipfw you cannot filter L2 MAC on pfil(9) level AFAIR. > > -- > Bjoern A. Zeeb =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 You have to have visions! > =A0 It does not matter how good you are. It matters what good you do! > --=20 Ermal From owner-freebsd-pf@FreeBSD.ORG Tue Apr 17 19:21: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 9DA0A106566B; Tue, 17 Apr 2012 19:21: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 4F4148FC1D; Tue, 17 Apr 2012 19:21:28 +0000 (UTC) Received: by iahk25 with SMTP id k25so12183458iah.13 for ; Tue, 17 Apr 2012 12:21:28 -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=H3YnSOaC3S3mCIUT0wixtdXMoP2tyOEwd/6Grxq8Syc=; b=e83PGa0KFJ9h3ibH1KgGi/3ithj1V4yVCq19w6r277Tz9wRWmqdn2yjLlS97XL1NwA mncdJFzgEXWnUmK11Y8F/JDKvayQe/hr3Uuf66qXi/8kjc9/spdJYGMPakK5hPDS1zHg wIkNljZSf74fKr8ABZmk8a9q70Zes6xkMZXxwDj3nxjxDNBPhPVU3UDLI0jcMDhlK/4n 7h7r+i5gUDnFDqMpVWxncdNMbIHul5wiXMcqE+SsO8AEybHEJGwW5g+8JANgHoj7IK+V mlFpuiOKsicymlcw21tJOpvRQkqB4CDCwq9KkqUMfBWWElC388wntMXFIyFUgO8tH9pK zjnw== MIME-Version: 1.0 Received: by 10.50.159.196 with SMTP id xe4mr10639463igb.17.1334690487996; Tue, 17 Apr 2012 12:21:27 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.231.243.65 with HTTP; Tue, 17 Apr 2012 12:21:27 -0700 (PDT) In-Reply-To: <20120417140205.GA2140@glebius.int.ru> References: <201204151200.q3FC0LT5085161@freefall.freebsd.org> <20120416185949.GC92286@FreeBSD.org> <20120417081406.GA93887@glebius.int.ru> <20120417084608.GA99119@glebius.int.ru> <20120417140205.GA2140@glebius.int.ru> Date: Tue, 17 Apr 2012 21:21:27 +0200 X-Google-Sender-Auth: C-V_B493BTJWNdrCmx-Oc8Rvq0s 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 19:21:28 -0000 2012/4/17 Gleb Smirnoff : > On Tue, Apr 17, 2012 at 12:46:08PM +0400, Gleb Smirnoff wrote: > T> We can make the assignment like: > T> > T> if (ifp->if_flags & IFF_LOOPBACK) > T> =A0 =A0 =A0m->m_flags |=3D M_SKIP_FIREWALL; > > I've tested this plus MTAG_PERSISTENT on pf tags, and it looks like this > works. > > At least for the "fastroute" case, which was defnitely not working before= . > fastroute has been never of any good use if you asked me. Though you can test reply-to quite easily the same you do with fastroute. This fix should fix another tickets which reported massive storms of icmp on lo0 as well. I have to find out the PR# though to merge it with this. > -- > Totus tuus, Glebius. --=20 Ermal From owner-freebsd-pf@FreeBSD.ORG Thu Apr 19 06:54:40 2012 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 998B4106566C for ; Thu, 19 Apr 2012 06:54:40 +0000 (UTC) (envelope-from zacisco@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 703F48FC12 for ; Thu, 19 Apr 2012 06:54:40 +0000 (UTC) Received: by dadz14 with SMTP id z14so35672696dad.17 for ; Wed, 18 Apr 2012 23:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qC1OsSCLRugg98ZHV+nbIZvccDj8KiM93GR/yI+yrKw=; b=Ue2USWGxapUPGhc93AUgOvPiiBPzI98SGdC7tbta3Vqq77G3VX4aPfMB6go2b/+2lN YezFjGQAt8enrlFfCWYF9r07Cw8Tb+rVOGlHaxf05KcJpnRBsoBJXxyYoBiuzSsd2dav r7JE2Wl9jU7oHOqRhew8uBUb9VL50HIKMhNr/omKkjXvicIhlw2NnEdkfdYgi0EHizM2 NOaHjqw4Yk8FVzMiYuHd6uqHjqwJETOhyqDxdaqdJp4mvq8mXS03oS+IQbpW6Yr6qwEK hzUSlkIabPROFi0FKUUx2uE4oRwW/HpfMNaihDQAGZkitmjGXWQfQCImDKWP+4FVNnNL qzFw== MIME-Version: 1.0 Received: by 10.68.220.99 with SMTP id pv3mr2793899pbc.53.1334818480071; Wed, 18 Apr 2012 23:54:40 -0700 (PDT) Received: by 10.68.135.98 with HTTP; Wed, 18 Apr 2012 23:54:40 -0700 (PDT) Date: Thu, 19 Apr 2012 10:54:40 +0400 Message-ID: From: =?UTF-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0J/QvtC60YDQvtCy0YHQutC40Lk=?= To: pf@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: PF NAT don't work 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: Thu, 19 Apr 2012 06:54:40 -0000 hello when you can fix problem with PF nat rules (they didn't work) don't check on earlier versions FreeBSD,but on 9.0 not work this function very very need thx i have two eth eth0 - external eth1 - internal in pf.conf: nat on $ext_if proto udp from $vpn_ip port 1194 to any -> $ext_ip port 2000 rdr on $ext_if proto udp from any to $ext_ip port 2000 -> $vpn_ip port 1194 rdr is work nat didn't vpnclient sent packets from internet to $vpn_ip,but not recieve it was 1st ... 2nd: and i have TeamSpeak 3 Server also if policy set block all then TS3 Server can't run (some connect?) i opened this ports: http://support.teamspeakusa.com/index.php?/Knowledgebase/Article/View/44/16/which-ports-does-the-teamspeak-3-server-use http://forum.configserver.com/viewtopic.php?f=6&t=4881 but i have still this problem if policy set pass all then it will be work i can run: pass all > TS3 > block all but then TS3 was can't check license can you help me? thx From owner-freebsd-pf@FreeBSD.ORG Fri Apr 20 01:11:09 2012 Return-Path: Delivered-To: pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D6B61065673 for ; Fri, 20 Apr 2012 01:11:09 +0000 (UTC) (envelope-from andriy@irbisnet.com) Received: from nm8-vm0.access.bullet.mail.mud.yahoo.com (nm8-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.191]) by mx1.freebsd.org (Postfix) with SMTP id 089F88FC0C for ; Fri, 20 Apr 2012 01:11:08 +0000 (UTC) Received: from [66.94.237.194] by nm8.access.bullet.mail.mud.yahoo.com with NNFMP; 20 Apr 2012 01:08:19 -0000 Received: from [98.139.221.70] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 20 Apr 2012 01:08:19 -0000 Received: from [127.0.0.1] by smtp107.rog.mail.bf1.yahoo.com with NNFMP; 20 Apr 2012 01:08:19 -0000 X-Yahoo-Newman-Id: 764675.83116.bm@smtp107.rog.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: orf12ksVM1k8jKx5I2M3jkFvAa6A62HxHPeHTd.e5w8UC7R VkU7b89FU1MaMZgPMoq84mER8_7fbOl8DInwb0_mHHu3LSEXc9.5mq5rV0Bu 3A4xjhSoD0CVhUZa1CFhxESWJxEa2P5Q3yFoliw2gBRLr5YbcgSCH7_cAqa9 pp_8Wnblz7TnfgWtX_NkptSRJb9QrRmEHI5gwKu8nzfcPKQbxuLyAcYrrCHn Q8_GsQER0isN9.nrcI_pne45XTzjWNIpKTP_3jOUppVhaL22JwpreQLVuVdI IBG0ILR3H2bWfBlkzXvPHqvI2K4AL5Q_AKhXnl9NFQxTBOAHX47SPsVcdkXb F8LTinYSgRqMNIuhM_40WKIpnSPgpQLXXLYzFAgz3h15vcjFPFYzE3wJFwXm zc8wRbd77uI4cUgAJykX6KdKAIfLIHSez9Dmoc7qDfFlLvksbRmQXzh97R7U rIR4oWg63s_Ea3YKO0cSvhPWLVXKqQd7_4T7ajVnDFJmzputeOB1_75P3gL4 3VIW8ZrJlOPtxqfitDEco9G0kJOyfG91tgZ7KtJ0.cCLcde_FMBl65TsbrSy voo2t31eymbrTa.sNlGcwFMw6fvsJSCyZhqB_20rwSa_ZPR.4568ph9LgYYP BrHyfBx_YFk49PrAaLz7CyKEnzveoGhsHiTUQfchiWC24guxiocu1b5_4D3u Iai5b.ZuxNgipgbJmYRlD9WtMt5iXCceWQDzRUqanvww8a6hi4NZk76s- X-Yahoo-SMTP: dz9sigaswBA5kWoYWVTZrGHmIs2vaKgG1w-- Received: from smtp.irbisnet.com (andriy@174.113.73.248 with login) by smtp107.rog.mail.bf1.yahoo.com with SMTP; 19 Apr 2012 18:08:19 -0700 PDT Received: from pollux.irbisnet.com (pollux.local [192.168.0.6]) by smtp.irbisnet.com (Postfix) with ESMTPSA id 4D6F330DFA; Thu, 19 Apr 2012 21:08:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: Andriy Bakay In-Reply-To: Date: Thu, 19 Apr 2012 21:08:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?B?0JrQvtC90YHRgtCw0L3RgtC40L0g0J/QvtC60YDQvtCy0YHQutC4?= =?utf-8?B?0Lk=?= X-Mailer: Apple Mail (2.1257) Cc: pf@freebsd.org Subject: Re: PF NAT don't work 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: Fri, 20 Apr 2012 01:11:09 -0000 On 2012-04-19, at 02:54 , =D0=9A=D0=BE=D0=BD=D1=81=D1=82=D0=B0=D0=BD=D1=82= =D0=B8=D0=BD =D0=9F=D0=BE=D0=BA=D1=80=D0=BE=D0=B2=D1=81=D0=BA=D0=B8=D0=B9 = wrote: > hello > when you can fix problem with PF nat rules (they didn't work) > don't check on earlier versions FreeBSD,but on 9.0 not work > this function very very need > thx >=20 > i have two eth > eth0 - external > eth1 - internal > in pf.conf: > nat on $ext_if proto udp from $vpn_ip port 1194 to any -> $ext_ip port = 2000 > rdr on $ext_if proto udp from any to $ext_ip port 2000 -> $vpn_ip port = 1194 >=20 I am not sure about '$ext_ip port 2000' condition in your NAT rule. Are = you using any proxy? Why do you need to explicitly specify outgoing = port? Make sure you have 'pass' rules for your RDR and NAT. Could you = provide more info about you VPN setup? As a general recommendation, you can always "debug" you ruleset with = 'tcpdump' utility, for example: $ sudo tcpdump -ttttnpei pflog0 Or you can use 'pftop' from ports. > rdr is work > nat didn't >=20 > vpnclient sent packets from internet to $vpn_ip,but not recieve > it was 1st ... >=20 > 2nd: > and i have TeamSpeak 3 Server also > if policy set block all then TS3 Server can't run (some connect?) > i opened this ports: > = http://support.teamspeakusa.com/index.php?/Knowledgebase/Article/View/44/1= 6/which-ports-does-the-teamspeak-3-server-use > http://forum.configserver.com/viewtopic.php?f=3D6&t=3D4881 > but i have still this problem > if policy set pass all then it will be work > i can run: pass all > TS3 > block all > but then TS3 was can't check license >=20 > can you help me? > thx > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"