Hi Daniel,
Yea we use sasynycd heavily and rely on it a lot! :) It works really well
for us.
For an idea of scale we have 6 sites (all running OpenBSD CARP pairs), and
each site has anything from 2 to 10 local LANs. We have configured a
full-mesh topology (every single LAN is connected to every single other
than).
As you can imagine that is a *lot* of tunnels so we use puppet to
dynamically generate the configs for them all. And it all works perfectly
with sasyncd. If any single firewall fails at any site, the tunnels are
running again really quickly with no lost states :)
Failover takes about 10 seconds after carp failover as sasysncd doesn't
fully replicate everything and so isakmpd requires some renegotiation with
the other end (not sure if its phase 1 or phase 2 that needs SPI's or SA's
updated or something).
The problems you read about in the mailing lists was solved by some minor
patches that we run to work around some issues regarding synchronisation of
the daemons depending on the CARP state.. They are messy and Theo and
others would laugh at me, but they are workarounds that do the job well for
us :) I'll try and find them for you..
Without them the tunnels can get confused and corrupt..
The problem you are describing sounds like one of a couple of problems.
The backup firewall is initialising in the wrong mode (either as active, or
is starting but not reading the config (one of my patches fixes this), or
you are not using the CARP IPs as the tunnel endpoints, or you have an
intra-operability issue with the remote end (is both ends OpenBSD?)..
NB; My 'patches' are not really patches as they are not code diff's. They
are just suggested changes i've posted on the lists. When I get more time
(I'm a one man band at the mo for my company!) I want to get more familiar
with the code base etc and contribute diffs to OBSD..
/etc/rc.d/sasyncd;
#!/bin/sh
#
# $OpenBSD: sasyncd,v 1.1 2011/07/06 18:55:36 robert Exp $
daemon="/usr/sbin/sasyncd"
. /etc/rc.d/rc.subr
pexp="sasyncd: \[priv\]"
rc_start() {
sleep 10
${rcexec} "${daemon} ${daemon_flags} ${_bg}"
sleep 5
ipsecctl -f /etc/ipsec.conf
}
rc_cmd $1
This ensures that when isakmpd is started on the backup in passive mode
with -S, it forces it to actually load the config/tunnels so when you fail
over to it, it is ready to do its job and understands sasyncd's messages!
;)
/etc/rc.d/isakmpd;
#!/bin/sh
#
# $OpenBSD: isakmpd,v 1.1 2011/07/06 18:55:36 robert Exp $
daemon="/sbin/isakmpd"
. /etc/rc.d/rc.subr
pexp="isakmpd: monitor \[priv\]"
rc_pre() {
[ X"${sasyncd_flags}" != X"NO" ] && \
daemon_flags="-S ${daemon_flags}"
return 0
}
rc_stop() {
if [ `ifconfig | grep "status: master" | wc -l` > 0 ]; then ipsecctl
-d -f /etc/ipsec.conf; fi
sleep 1
if [ `ifconfig | grep "status: master" | wc -l` > 0 ]; then ipsecctl
-d -f /etc/ipsec.conf; fi
if [ `ifconfig | grep "status: master" | wc -l` > 0 ]; then ipsecctl
-F -f /etc/ipsec.conf; fi
pkill -f "^${pexp}"
}
rc_cmd $1
This one is unusual but the idea is that it performs a graceful delete
before shutdown (which sends a shutdown to the other side to delete the
SA's on the other side). Without this isakmpd just goes down and the other
side thinks its still up. So when you then restart it, the other-side is
confused (this freaks out cisco's).
Also be careful of your tunnel configs... You need DPD etc to make this
work;
# Remote nets
newyork_gw="nyfw.brandwatch.net"
newyork_lan="10.32.0.0/24"
local_lan="10.10.10.0/24"
local_gw="<my carp IP address>"
ike dynamic esp from $local_lan to $newyork_lan \
local $local_gw peer $newyork_gw \
main auth hmac-sha2-256 enc aes group modp1024 \
quick auth hmac-sha2-256 enc aes group modp1024 \
srcid $local_gw dstid $newyork_gw \
psk <removed :)>
Hope this helps.
Andrew Lemin
On Mon, 12 May 2014 11:42:09 +0100, Stuart Henderson <s...@spacehopper.org>
wrote:
> On 2014/05/12 12:11, Daniel Polak wrote:
>> Hi Andy, Anders and Stuart,
>>
>> I have just configured a pair of carped firewalls to do VPN failover
with
>> sasyncd.
>>
>> I'm having an issue where after a little while (don't know why it isn't
>> immediate) all the flows are visible on the backup firewall but 2 of
the
>> 6
>> entries of the SAD are missing.
>> While searching the mailing list I found a few threads where you are
>> conversing about serious sasyncd problems (such as SA sync problems and
>> "the
>> machines got in a state where not even shutting down ipsec
>> related daemons and "ipsecctl -F" was enough to get them out of it").
>> From what I read there it seems it doesn't quite do the job.
>>
>> I don't see any recent code changes in cvs so sasyncd must either be
>> working
>> or it is a little bit of an orphan.
>> Are any of you using sasyncd in production? If so is it reliable or are
>> there limitations?
>>
>> Best regards,
>>
>> Daniel
>>
>>
>>
>
> I think it is a bit of an orphan. I have heard of people using it,
> but no longer do so myself, in most cases I control both sides of the
> connection and just use DPD (the main case where I don't control both
> sides is cisco + nat-t which is running on an ASA5505 instead because
> isakmpd doesn't interop well with that).
