From owner-freebsd-pf@FreeBSD.ORG Mon May 4 11:08:00 2009 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 291161065672 for ; Mon, 4 May 2009 11:08:00 +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 EF8DB8FC17 for ; Mon, 4 May 2009 11:07:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n44B7x2s098771 for ; Mon, 4 May 2009 11:07:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n44B7wb8098758 for freebsd-pf@FreeBSD.org; Mon, 4 May 2009 11:07:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 May 2009 11:07:58 GMT Message-Id: <200905041107.n44B7wb8098758@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, 04 May 2009 11:08:00 -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/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 f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] 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/121704 pf [pf] PF mangles loopback packets 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 o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 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 31 problems total. From owner-freebsd-pf@FreeBSD.ORG Thu May 7 20:07:11 2009 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 517481065672 for ; Thu, 7 May 2009 20:07:11 +0000 (UTC) (envelope-from ml@infosec.pl) Received: from v027580.home.net.pl (v027580.home.net.pl [89.161.156.148]) by mx1.freebsd.org (Postfix) with SMTP id E034C8FC12 for ; Thu, 7 May 2009 20:07:10 +0000 (UTC) (envelope-from ml@infosec.pl) Received: from localhost (HELO ?192.168.1.66?) (ml.freeside@home@127.0.0.1) by m094.home.net.pl with SMTP; Thu, 7 May 2009 19:40:36 -0000 Message-ID: <4A03391B.6070009@infosec.pl> Date: Thu, 07 May 2009 20:40:11 +0100 From: Michal User-Agent: Thunderbird 2.0.0.21 (X11/20090415) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: state of pf port in 8.x 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, 07 May 2009 20:07:11 -0000 Hello, Any ideas what's cooking for 8.0 in this regard? Optimistically assuming that we'll see 8.0 in September this year, are we getting equivalent of OpenBSD 4.5 or porting is not that easy and straightforward? Michal -- "There cannot be a crisis next week. My schedule is already full." -Henry Kissinger From owner-freebsd-pf@FreeBSD.ORG Fri May 8 12:52:44 2009 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 09AC61065672; Fri, 8 May 2009 12:52:44 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id CFB4B8FC16; Fri, 8 May 2009 12:52:38 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: by rv-out-0506.google.com with SMTP id k40so1179851rvb.43 for ; Fri, 08 May 2009 05:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=njbKUVuoTzGI/VkqhhWqZBAr15OJfuPI3x6oBIyFNn8=; b=A3eopLh4TlTHWLIVrM9693wMHd8QN23K2ja6W6MpRItfFtBr9MbilBECOYXj+2aHOg 4oSYjeWIhjXJ1LRSY+T5e2txFDMHyj0GsYCxS2P97ek7KnN8c2K0E2xaf4e4GEbOs9+g Zh9m125ghocuiBXWd+h4hxjGbV+I3h4UAf3OM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=To6CcBmoAvxjAYcmeYNM91Sq3tWRrciehGnDDDjaHRpWn/o1V4+lzbZqfcVMuRhe+3 2gA2z9OFVYVotNwDW2xQiXA/67K/0ZhiKN6GXIWDYtLPD+4q17C8MkYIYjKSJ5/McKwG QO2gl+mdjgL3XgBrxWtdZC+9+LhrWcFmuiSz0= MIME-Version: 1.0 Received: by 10.142.133.19 with SMTP id g19mr1660550wfd.126.1241787158567; Fri, 08 May 2009 05:52:38 -0700 (PDT) Date: Fri, 8 May 2009 22:52:38 +1000 Message-ID: <736c47cb0905080552r70f45368va5dfa5af24720c1c@mail.gmail.com> From: Sam Wun To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Can pfsync be used over router or WAN? 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, 08 May 2009 12:52:44 -0000 Hi, Have anyone tried pfsync over router or WAN? I have read setup guide of CARP+pfsync, the pfsync interface is connected through a crossover cable. Can I connect 2 pfsync interfaces through a router or WAN? Thanks From owner-freebsd-pf@FreeBSD.ORG Fri May 8 17:06:28 2009 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 8663C106566B; Fri, 8 May 2009 17:06:28 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from relay1-bcrtfl2.verio.net (relay1-bcrtfl2.verio.net [131.103.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 33B258FC12; Fri, 8 May 2009 17:06:28 +0000 (UTC) (envelope-from ddesimone@verio.net) Received: from iad-wprd-xchw01.corp.verio.net (unknown [198.87.7.164]) by relay1-bcrtfl2.verio.net (Postfix) with ESMTP id B3E51B0380BB; Fri, 8 May 2009 12:44:34 -0400 (EDT) thread-index: AcnP/ER2T47ExsyCTsmlWT64j+Gnhw== Received: from dllstx1-8sst9f1.corp.verio.net ([10.144.0.1]) by iad-wprd-xchw01.corp.verio.net over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 May 2009 12:44:33 -0400 Received: by dllstx1-8sst9f1.corp.verio.net (sSMTP sendmail emulation); Fri, 08 May 2009 11:44:32 +0000 Date: Fri, 8 May 2009 11:44:32 -0500 From: "David DeSimone" Content-Transfer-Encoding: 7bit To: Importance: normal Priority: normal Content-Class: urn:content-classes:message Message-ID: <20090508164432.GW2160@verio.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Mail-Followup-To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org References: <736c47cb0905080552r70f45368va5dfa5af24720c1c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <736c47cb0905080552r70f45368va5dfa5af24720c1c@mail.gmail.com> Precedence: bulk User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 08 May 2009 16:44:33.0207 (UTC) FILETIME=[43BF0470:01C9CFFC] Cc: freebsd-net@freebsd.org Subject: Re: Can pfsync be used over router or WAN? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 08 May 2009 17:06:28 -0000 Sam Wun wrote: > > Have anyone tried pfsync over router or WAN? > I have read setup guide of CARP+pfsync, the pfsync interface is > connected through a crossover cable. Can I connect 2 pfsync > interfaces through a router or WAN? pfsync(4) talks about this: NETWORK SYNCHRONISATION States can be synchronised between two or more firewalls using this interface, by specifying a synchronisation interface using ifconfig(8). For example, the following command sets fxp0 as the synchronisation interface: # ifconfig pfsync0 syncdev fxp0 It is important that the underlying synchronisation interface is up and has an IP address assigned. By default, state change messages are sent out on the synchronisation interface using IP multicast packets. The protocol is IP protocol 240, PFSYNC, and the multicast group used is 224.0.0.240. When a peer address is specified using the syncpeer keyword, the peer address is used as a destination for the pfsync traffic, and the traffic can then be protected using ipsec(4). In such a configuration, the syncdev should be set to the enc(4) interface, as this is where the traffic arrives when it is decapsulated, e.g.: # ifconfig pfsync0 syncpeer 10.0.0.2 syncdev enc0 It is important that the pfsync traffic be well secured as there is no authentication on the protocol and it would be trivial to spoof packets which create states, bypassing the pf ruleset. Either run the pfsync protocol on a trusted network - ideally a network dedicated to pfsync messages such as a crossover cable between two firewalls, or specify a peer address and protect the traffic with ipsec(4). For pfsync to start its operation automatically at the system boot time, pfsync_enable and pfsync_syncdev variables should be used in rc.conf(5). It is not advisable to set up pfsync with common network interface configuration variables of rc.conf(5) because pfsync must start after its syncdev, which cannot be always ensured in the latter case. Syncing over a WAN doesn't seem like it would make sense, offhand. Normally you psync between devices that will be able to provide routing for a firewalled connection. A device far across a WAN doesn't seem like it would be able to provide redundant service. But that's up to your design, I suppose. Syncing across a LAN could make sense, but you will want to take steps to secure the traffic. -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From owner-freebsd-pf@FreeBSD.ORG Sat May 9 00:54:25 2009 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 8035B106566C; Sat, 9 May 2009 00:54:25 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: from mail-ew0-f159.google.com (mail-ew0-f159.google.com [209.85.219.159]) by mx1.freebsd.org (Postfix) with ESMTP id D557A8FC15; Sat, 9 May 2009 00:54:24 +0000 (UTC) (envelope-from swun2010@gmail.com) Received: by ewy3 with SMTP id 3so2211111ewy.43 for ; Fri, 08 May 2009 17:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=1EOsYG2m8/uABxfPR6KEweluIblFFmAemm5P2nLgJvw=; b=u/VhqVfOLiadQLl+rk698m0Kg5k7HwtFv6f9g1AnND1Yp4ZEFYIHe6kJyHjamb2pQr mWsLu54uniGim1NiVDSOIzlXVqu06oeEnwnJT1MNb4UPaUXF3abnpvXuewJLI1puNyED reQGfgbloEn3U+uddgn33CzLT1HnzfOHKhVEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ZDk+jHBTHJGQH9pojgtjjX5qdxqcGdUoRJBh8OhTBHuYw7fuwA0AdNj+yC2BKyO9Ai NaOyyMM4o2aKVdArKOQyVwlHfrEv+28TLSPXkv3+rwv2ZddOm2Wn5wETdWy5+nuYhdh9 qVuL9tZKA1Vr0bfXeeBAr7K5Qhf4W9kUUKvV0= MIME-Version: 1.0 Received: by 10.210.88.3 with SMTP id l3mr1579109ebb.55.1241830463968; Fri, 08 May 2009 17:54:23 -0700 (PDT) In-Reply-To: <20090508164432.GW2160@verio.net> References: <736c47cb0905080552r70f45368va5dfa5af24720c1c@mail.gmail.com> <20090508164432.GW2160@verio.net> Date: Sat, 9 May 2009 10:54:23 +1000 Message-ID: <736c47cb0905081754s32d9414fhe89f1920c8675869@mail.gmail.com> From: Sam Wun To: freebsd-pf@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Can pfsync be used over router or WAN? 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: Sat, 09 May 2009 00:54:26 -0000 Establish a IPSEC bewteen this 2 pfsync points is a way to go. On Sat, May 9, 2009 at 2:44 AM, David DeSimone wrote: > Sam Wun wrote: >> >> Have anyone tried pfsync over router or WAN? >> I have read setup guide of CARP+pfsync, the pfsync interface is >> connected through a crossover cable. =A0Can I connect 2 pfsync >> interfaces through a router or WAN? > > pfsync(4) talks about this: > > =A0 =A0NETWORK SYNCHRONISATION > =A0 =A0 =A0 =A0 States can be synchronised between two or more firewalls = using > =A0 =A0 =A0 =A0 this interface, by specifying a synchronisation interface= using > =A0 =A0 =A0 =A0 ifconfig(8). =A0For example, the following command sets f= xp0 as > =A0 =A0 =A0 =A0 the synchronisation interface: > > =A0 =A0 =A0 =A0 =A0 # ifconfig pfsync0 syncdev fxp0 > > =A0 =A0 =A0 =A0 It is important that the underlying synchronisation inter= face > =A0 =A0 =A0 =A0 is up and has an IP address assigned. > > =A0 =A0 =A0 =A0 By default, state change messages are sent out on the > =A0 =A0 =A0 =A0 synchronisation interface using IP multicast packets. =A0= The > =A0 =A0 =A0 =A0 protocol is IP protocol 240, PFSYNC, and the multicast gr= oup > =A0 =A0 =A0 =A0 used is 224.0.0.240. =A0When a peer address is specified = using > =A0 =A0 =A0 =A0 the syncpeer keyword, the peer address is used as a desti= nation > =A0 =A0 =A0 =A0 for the pfsync traffic, and the traffic can then be prote= cted > =A0 =A0 =A0 =A0 using ipsec(4). =A0In such a configuration, the syncdev s= hould > =A0 =A0 =A0 =A0 be set to the enc(4) interface, as this is where the traf= fic > =A0 =A0 =A0 =A0 arrives when it is decapsulated, e.g.: > > =A0 =A0 =A0 =A0 =A0 # ifconfig pfsync0 syncpeer 10.0.0.2 syncdev enc0 > > =A0 =A0 =A0 =A0 It is important that the pfsync traffic be well secured a= s > =A0 =A0 =A0 =A0 there is no authentication on the protocol and it would b= e > =A0 =A0 =A0 =A0 trivial to spoof packets which create states, bypassing t= he > =A0 =A0 =A0 =A0 pf ruleset. =A0Either run the pfsync protocol on a truste= d > =A0 =A0 =A0 =A0 network - ideally a network dedicated to pfsync messages = such > =A0 =A0 =A0 =A0 as a crossover cable between two firewalls, or specify a = peer > =A0 =A0 =A0 =A0 address and protect the traffic with ipsec(4). > > =A0 =A0 =A0 =A0 For pfsync to start its operation automatically at the sy= stem > =A0 =A0 =A0 =A0 boot time, pfsync_enable and pfsync_syncdev variables sho= uld be > =A0 =A0 =A0 =A0 used in rc.conf(5). =A0It is not advisable to set up pfsy= nc with > =A0 =A0 =A0 =A0 common network interface configuration variables of rc.co= nf(5) > =A0 =A0 =A0 =A0 because pfsync must start after its syncdev, which cannot= be > =A0 =A0 =A0 =A0 always ensured in the latter case. > > Syncing over a WAN doesn't seem like it would make sense, offhand. > Normally you psync between devices that will be able to provide routing > for a firewalled connection. =A0A device far across a WAN doesn't seem > like it would be able to provide redundant service. =A0But that's up to > your design, I suppose. > > Syncing across a LAN could make sense, but you will want to take steps > to secure the traffic. > > -- > David DeSimone =3D=3D Network Admin =3D=3D fox@verio.net > =A0"I don't like spinach, and I'm glad I don't, because if I > =A0 liked it I'd eat it, and I just hate it." -- Clarence Darrow > > > This email message is intended for the use of the person to whom it has b= een sent, and may contain information that is confidential or legally prote= cted. If you are not the intended recipient or have received this message i= n error, you are not authorized to copy, distribute, or otherwise use this = message or its attachments. Please notify the sender immediately by return = e-mail and permanently delete this message and any attachments. Verio, Inc.= makes no warranty that this email is error or virus free. =A0Thank you. > _______________________________________________ > 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" > From owner-freebsd-pf@FreeBSD.ORG Sat May 9 18:16:18 2009 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 189D81065674 for ; Sat, 9 May 2009 18:16:18 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id C59488FC13 for ; Sat, 9 May 2009 18:16:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 3F7FB341515; Sat, 9 May 2009 14:00:35 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 09 May 2009 14:00:35 -0400 X-Sasl-enc: hcPhZGpb9iA08SrTrHTTLQHiBZiZYccLB7iepx+kXUQC 1241892034 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id F251224695; Sat, 9 May 2009 14:00:33 -0400 (EDT) Message-ID: <4A05C4BA.2090506@incunabulum.net> Date: Sat, 09 May 2009 19:00:26 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Sam Wun References: <736c47cb0905080552r70f45368va5dfa5af24720c1c@mail.gmail.com> <20090508164432.GW2160@verio.net> <736c47cb0905081754s32d9414fhe89f1920c8675869@mail.gmail.com> In-Reply-To: <736c47cb0905081754s32d9414fhe89f1920c8675869@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Can pfsync be used over router or WAN? 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: Sat, 09 May 2009 18:16:18 -0000 Sam Wun wrote: > Establish a IPSEC bewteen this 2 pfsync points is a way to go. > Yup. The key observation about pfsync is that you can configure the peer(s) for synchronization in the 'syncdev' mode or the 'syncpeer' mode. Unlike CARP, pfsync(4) has no authentication built-in. With syncdev, you are telling pfsync to periodically send out state updates to a link-scope IPv4 multicast group. Obviously, this only works if all the peer(s) are on-link (i.e. the same LAN), and any Layer 2 switches in the middle are configured to forward the multicast traffic. The IGMP code will send a membership report for the 224.0.0.240 address, unless it's configured explicitly to not do so for 224.0.0.0/24 link-scope groups via sysctl, which should appease snooping switches. Note that it defaults to IGMPv3 in HEAD, it should downgrade to v2 or v1 if it sees a v2 Query. This mechanism operates wholly independently of CARP. You can IPSEC encapsulate multicast traffic, but of course that gives rise to 'interesting' key distribution problems. With syncpeer, you are telling pfsync to periodically send out state updates to a *single* peer, not a list, and all such traffic is unicasted. As far as I know, you can't specify multiple peers, so you are limited to 1 other member (unless the peer address is a CARP address, or anycasted by some other mechanism). This should work just fine with IPSEC, provided your key distribution is taken care of. If your WAN link can carry multicast traffic without additional encapsulation (most can, even if they're not link-layer multicast-capable), then using 'syncdev' should work fine, although the IGMP and MLD code in HEAD will suppress sending membership reports on interfaces without the IFF_MULTICAST flag. This doesn't disallow the stack from sending multicast traffic, though. [This should perhaps be revisited, because I can think of situations where the WAN link may not have a native link-layer multicast capability, but it's still desirable for the IGMP/MLD reports to go upstream, i.e. DSL in ATM native mode. Userland PPP via tun(4) needs to be told to enable IFF_MULTICAST with the TUNSIFMODE ioctl]. For those who are interested in experiments: pfsync(4) could in theory be enhanced to use Source-Specific Multicast (SSM) for pushing pf state to multiple border firewalls inside an AS boundary -- but it would require knowing all the addresses of the peer(s), and you'd be dependent on a multicast routing protocol like PIM at a minimum for distributing the traffic throughout your AS, as well as needing a unicast routing IGP for the traffic to pass the uRPF checks. It would be desirable to use a different address for this than 224.0.0.240. You could probably get away with Any-Source Multicast (ASM) for distributing the pfsync updates, but I'd advise against that, as ASM is a little bit harder to secure -- you don't/can't control the endpoints without explicit firewall rules, and of course that introduces recursion (you're having to firewall your firewall updates...) For kernel hacking: The KPIs involved require that kernel consumers do their own SSM housekeeping, though -- splicing of consumer layer memberships is only done for sockets, and you'd have to craft your own RB-trees, although the multicast code takes care of knitting together the right state-change reports to send upstream, doing filter matches etc -- that's a different matter. It's for this reason that SSM apps are generally best written in userland. Doing SSM in-kernel is possible, sure, but the whole point of using a socket for it is that a load of stuff gets taken care of for you, and using a socket in-kernel is still irksome. Obviously the more mechanisms you introduce to push out the updates, the wider the range of possible points of failure you introduce. pfsync is cool because it's a tightly integrated solution to a common problem in its space, but it may not be the right choice for all folks in its present state. ... By the way, does anyone out there have patches to get pfsync(4) to work over IPv6? cheers, BMS