On Tue, Feb 26, 2013 at 9:11 AM, sven falempin <[email protected]> wrote: > > > On Tue, Feb 26, 2013 at 8:09 AM, sangdrax8 <[email protected]> wrote: >> >> On Mon, Feb 25, 2013 at 3:06 PM, Stuart Henderson <[email protected]> >> wrote: >> > On 2013/02/25 14:41, sangdrax8 wrote: >> >> Any chance someone has the time/knowledge to squash this bug? I >> >> would like to deploy some syncing firewall/vpn devices but as they >> >> are right now I can't put this in my production environment. >> > >> > Do you actually need sync? If you're in a situation where you can >> > use dead peer detection then you can use ifstated to start up ipsec >> > when a box becomes carp master and to kill/flush when a box becomes >> > carp backup which has been working quite well for me. >> > >> > Not saying that a fix wouldn't be nice, but sasync has been known >> > to have problems for some time.. >> > >> >> The reason I was looking at OpenBSD for this project was the prospect >> of having the sasync for seamless redundancy. I believe I understand >> what you have suggested, and that should avoid the bug by creating >> new associations every time. That would also ensure that each failure >> would result in lost packets while the new master builds the tunnel. >> >> I won't give up yet on my seamless failure, but I guess I will have to >> look for ways around the bug. Perhaps if I use isakmpd's fifo I can >> clear only the phase 1 when switching from carp master to backup, >> while still allowing sasync to keep phase 2 associations in sync. >> Then I would not require lost packets, but each time there was a >> failure it would re-build the phase one. I will look into this further as >> my time permits, although adding complexity to avoid a bug is not >> usually the ideal solution to a problem. >> >> It is disappointing if the main feature I was looking to use, is accepted >> as non-functional. If anyone has interest in fixing sasync to provide >> true redundancy (with no loss) I would be very interested in hearing >> from them. In it's current state I would assume someone could >> easily set it up and believe they are redundant, when in reality they >> have a very real chance of taking them self down for a very extended >> outage. >> >> Is there a difference in filing a bug to the bug mailing list, as >> opposed to my query here on the tech list? >> > > imVHo > for me the workaround is reboot when you become slave, after sending alert > thus give you slave working to slave break time to do whatever you want. > > I guess people have no time to fix this right now, > are you ready to put money on the table .... ? > > > -- > --------------------------------------------------------------------------------------------------------------------- > () ascii ribbon campaign - against html e-mail > /\
So I have a band-aid that seems to provide the no loss failover that I was looking for. For anyone wanting the band-aid, you need to be running isakmpd.conf with out ispec.conf. Then you can use ifstated as mentioned earlier to watch for switches to SLAVE on the carp interface. When it is detected, you can remove all phase 1 associations on the box with out breaking the phase 2. I just made a shell script to find all hosts in isakmpd.conf and echo the tear down of phase 1 into the fifo. When the box takes back over as MASTER the phase 2's which sasync is keeping in sync allows seamless traffic, while new phase 1's can be brought up. I will need further testing, but so far this appears to get around my initial failure case. If a developer knows sasync enough to look at fixing it that would obviously be a better solution than working around the bug. I can talk to my employeer and see if we would like to sponsor some work in this area.
