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