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