From owner-freebsd-stable@FreeBSD.ORG Fri Jun 1 08:10:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27854106566B for ; Fri, 1 Jun 2012 08:10:51 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A15AC8FC0C for ; Fri, 1 Jun 2012 08:10:49 +0000 (UTC) Received: by eaac13 with SMTP id c13so122715eaa.13 for ; Fri, 01 Jun 2012 01:10:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=yffNFqvcmZyB4VY8JcKNHwM158af3myNT6IeF3On0LM=; b=gaV05hOYlbiHeHtwx+ZyZVsfHuU/GRBpc/piiTh802Vp6cLDxvf+TpI8lREmY7GZZK CsDhbGDEMvUmCWUxiMUKDaseRDGWTTQPsOP5QTDMyZioxtl96efE7KJwWd1+A7hGtad2 gTcCrZ+2eJ9fXoote+t0hHfuU52AMQIWv/ZZLyfWVUi+l+RZhuv15fN3gWY6IY5ykbKP 1jpz5r9NqJeW6oFqxcn/CwdjiEsbxtq/m7Ib3T/25Xk/s+IWAyZvStqSEW/M27ATOnk/ j1PaZZpyHWUPIIB2oB3PNFyx1lzDgltc78wp4xcqwxL4QsE4aPkypoIOMSkpgiVW/PFy yyDA== Received: by 10.14.97.137 with SMTP id t9mr953187eef.73.1338538248339; Fri, 01 Jun 2012 01:10:48 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id u7sm4079124eeb.7.2012.06.01.01.10.46 (version=SSLv3 cipher=OTHER); Fri, 01 Jun 2012 01:10:47 -0700 (PDT) Message-ID: <4FC87905.30308@my.gd> Date: Fri, 01 Jun 2012 10:10:45 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nick Gustas References: <4FC779C0.7020801@ohlste.in> <4FC77EAD.1090900@my.gd> <4FC78A94.8070008@ohlste.in> <4FC79136.6000205@my.gd> <4FC79E45.4060505@gmx.com> <4FC7A1DB.6040409@my.gd> <4FC7CBBC.6090204@tychl.net> In-Reply-To: <4FC7CBBC.6090204@tychl.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlo0Q8Wqn5/je2IQrVI3PtleOTehbbmsI5CxlELulwxBKnpVmU6jKcobf5mWjQIYiI6VVv1 Cc: freebsd-stable@freebsd.org Subject: PFsync firewall states updates (was: Re: Why Are You Using FreeBSD?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 08:10:51 -0000 On 5/31/12 9:51 PM, Nick Gustas wrote: > On 5/31/2012 12:52 PM, Damien Fleuriot wrote: >> On 5/31/12 6:37 PM, Nikos Vassiliadis wrote: >>> On 5/31/2012 5:41 PM, Damien Fleuriot wrote: >>>> Furthermore, when upgrading the CARP Master firewall, we need to plan >>>> with the Project Manager a failover to the CARP Backup firewall. >>>> Yes, I know about pfsync, yes, we use it, no, it doesn't *instantly* >>>> sync sessions for PF. >>> A bit offtopic on this thread, but isn't pfsync designed to do just >>> that? instantly? >>> >>> With instantly I really mean: >>> Communicate every change to the stable table to the other firewall >>> in order to let the stateful connections survive a firewall failover. >>> Obviously, some packets will be lost, but TCP connections should >>> survive, right? >>> >>> I am not arguing, I ask. >>> >>> Nikos >> Updates aren't instantaneous, they're sent in bundles. >> >> This means that when you failover, you lose the connections that have >> completed a SYN/SYNACK/ACK sequence on your main firewall but which >> aren't synched on your backup. >> >> These connections will continue with the peer sending regular non-syn >> packets, which your backup-now-master PF will drop. >> >> >> On topic, if anyone has an awesome idea around this, I'm all ears, this >> exact topic is causing us some level of discomfort at work, when we need >> to swap firewalls for updates. >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I don't see this option on FreeBSD 9, but on OpenBSD pfsync has a defer > flag that would appear to address your issue. > > The options are as follows: > > defer Defer transmission of the first packet in a state until a peer > has acknowledged that the associated state has been inserted. > See pfsync(4) for more information. > > -defer Do not defer the first packet in a state. This is the > default. > > > From pfsync(4) > > The pfsync interface will attempt to collapse multiple state > updates into > a single packet where possible. The maximum number of times a single > state can be updated before a pfsync packet will be sent out is con- > trolled by the maxupd parameter to ifconfig (see ifconfig(8) and > the ex- > ample below for more details). The sending out of a pfsync packet > will > be delayed by a maximum of one second. > > Where more than one firewall might actively handle packets, e.g. with > certain ospfd(8), bgpd(8) or carp(4) configurations, it is > beneficial to > defer transmission of the initial packet of a connection. The pfsync > state insert message is sent immediately; the packet is queued > until ei- > ther this message is acknowledged by another system, or a timeout > has ex- > pired. This behaviour is enabled with the defer parameter to > ifconfig(8). > > > > I'm sure this could be ported over. > > -Nick > This mimics the behavior of some manufacturers like Juniper and is *definitely* the kind of option we're looking for. While I lack the skills to port this, I'm definitely available for testing.