On Sat 09 Nov 2013 15:57:14 GMT, [email protected] wrote:
PS; We are against 'sloppy state' so much because we cannot sanitize
the sessions anywhere else (these firewalls connect to raw Transit).
In the meantime I think we're going to be forced to use ifstated to
shutdown OpenBGPd on the backup :(
Ugly and very slow, but I would rather this than risk insecurity..
Thanks for reading :)
I have (I think) almost exactly the same issue; doesn't pfsync between the
redundant BGP routers solve your state-tracking problem?
In my case, I have two BGP routers communicating with one upstream peer
(one session per router), *not* using the CARP IP to establish BGP
sessions. I had started with one BGP session originating from the CARP
IP, but every time I failed over, all my announcements went away and
instead of a ~60sec outage I had a ~4hr partial outage while my routes
re-propagated and foreign ASes stopped damping the change.
At the moment, I've disabled pf altogether, but preliminary testing shows
that using pfsync solves my problem - both routers maintain the same state
table, so it no longer matters which router processes any given packet
(AFAICT).
-Adam Thompson
[email protected]
Hi Adam,
It almost works.. Sadly I believe the pfsync delay can be higher than
the sessions RTT and so it wont always work. I.e. the internal server
replies before the other firewall has got the state..
The only way that I know of to make it work properly is to use either
'defer on' which slows down all connections as I believe it waits for
the other firewall to commit and confirm the state update, or 'sloppy
state' which is a big security risk as these are our only firewalls..
Is my understanding correct?
We have an internal network with many VLANs and these two firewalls
with connections to a Transit. We need to dual stack (start working
with routed v6 (and some routed v4) traffic etc in addition to the
legacy NAT) but I cannot see that this is currently possible without
employing one of the above methods which is extremely undesirable. As
such we can't dual stack (packet filtering and BGP routing with CARP)
using OpenBSD at the moment.
The ability to control BGP attribute values based on CARP state would
resolve this.
NB; These firewalls will be shifting about 1-2 Gbps and near 1 million
pps, so the pfsync latency is going to be /high/ even if I increase the
pfsync MTU..
