Date: Fri, 01 Jun 2012 10:10:45 +0200 From: Damien Fleuriot <ml@my.gd> To: Nick Gustas <freebsd-lists@tychl.net> Cc: freebsd-stable@freebsd.org Subject: PFsync firewall states updates (was: Re: Why Are You Using FreeBSD?) Message-ID: <4FC87905.30308@my.gd> In-Reply-To: <4FC7CBBC.6090204@tychl.net> References: <C480320C-0CD9-4B61-8AFB-37085C820AB7@FreeBSD.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FC87905.30308>