>
> hmm dont think i even need the keepalive without nat-t. think im getting
> that confused with the lifetime of phase 2. now that i think about it i have
> seen similar issues with cisco devices with mismatched lifetime's. hmm ill
> take a look at that tomorrow. its getting late.
>
> On 5/7/07,
askthelist@gmail.com <askthelist@gmail.com> wrote:
> >
> > Hmm, both sides are OpenBSD. I did have one side bsd, one side pix with
> > the vpn going without any issues during a data center/ip migration some
> > months back, but not using cisco anymore. Not using NAT on either side
> > either, so I can probably specify the -T to disable the Nat-T. I'll be back
> > on this tomorrow morning so ill see if I can find anything on the keep alive
> > for the phase 2 connection. Didnt think about that at all. Thanks for the
> > advice.
> >
> > On 5/7/07, Dag Richards < dagrichards@speakeasy.net> wrote:
> > >
> > > Yes I have seen this before, the otherside was a cisco box and I had
> > > to
> > > set keep alives for that phase 2 connection. I can no longer find an
> > > example of the config with that entry. You might want to set the
> > > global
> > > NAT-T keep alive or use -T to disable Nat traversal ....
> > >
> > > Let me know when you get back on this, my stuff stays up for months
> > > without issue.
> > >
> > >
> > >
askthelist@gmail.com wrote:
> > > > after reading your email which validated my setup i was convinced i
> > > had
> > > > something misconfigured so sure enough when i went back to look I
> > > had
> > > > the wrong ip on one of the isakmpd.conf files for the peer address.
> > > > after fixing this I was able to bring up the vpn on both hosts and
> > > fail
> > > > over successfully. I now seen the flows/sa's/spi's on both hosts
> > > which i
> > > > wasnt seeing before.
> > > >
> > > > however i did run into problems. towards the later part of the day
> > > after
> > > > the vpn/sasyncd had been running for hours and I was no longer
> > > messing
> > > > with the configurations I had connections drop mysteriously. I ran
> > > > ipsecctl -sa on both hosts running sasyncd locally and verified they
> > >
> > > > were still sharing info, but when i ran ipsecctl -sa on the remote
> > > hosts
> > > > the flows/sa's/spi's were gone. I'm not sure why my flows/sa's/spi's
> > > > dropped remotely all of a sudden but I killed isakmpd on all hosts.
> > > I
> > > > haven't had a chance to debug the situation, but will be real soon
> > > as it
> > > > is one of my highest priorities this week.
> > > >
> > > > have you seen this behaviour before?
> > > >
> > > > On 5/6/07, *Dag Richards* <
dagrichards@speakeasy.net
> > > > <mailto: dagrichards@speakeasy.net>> wrote:
> > > >
> > > >
askthelist@gmail.com <mailto:askthelist@gmail.com> wrote:
> > > > > Ok that setup is similar to what I have and I do have carp
> > > > interfaces on
> > > > > both sides of the firewall. I was able to configure sasynd
> > > but when
> > > > > running netstat -rnf encap was not able to see any of the
> > > flows
> > > > on the
> > > > > slave machine, but then I realized or thought that it was
> > > because
> > > > the
> > > > > ISAKMPD session was not established on the slave machine.
> > > > >
> > > > > If your trying to establish the ISAKMPD session from the
> > > slave
> > > > box which
> > > > > does not have control of the active carp interface, how is
> > > the
> > > > > ISAKMPD/IPSEC connection established? Doesn't it need to be
> > > > established
> > > > > for sasynd to know about the SA's? or upon failover does the
> > > session
> > > > > then get established on the fly? Do you use isakmpd.conf or
> > > > ipsec.conf
> > > > > to control your flows?
> > > > >
> > > > > Thanks.
> > > >
> > > > What's the status on this?
