PFsync firewall states updates (was: Re: Why Are You Using FreeBSD?)

[Damien Fleuriot]

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 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at 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.