On Thu, 30 Sep 2004, Chris Buechler wrote:
> Well, new issues with my PIX <-> m0n0wall VPN. I'm pretty sure this
> time it's because of the byte limit imposed by the PIX. If I'm
> transferring heavily over the connection, it'll drop after a while.
> No duplicate SA's exist on the m0n0wall side this time. The log
> messages on the PIX side are the same as before.
When it's in the failing state, look at the SAs on both sides. On
m0n0wall, you'll need to use "setkey -D", since not all the information of
interest is shown in the GUI SAD display. I don't know what the Cisco
equivalent is. Look in particular at the SPIs, but also the lifetime
Then look at the logs to see when the SAs were established, and when they
expired (in the event of a mismatch). Note that the expirations reported
in the m0n0wall log are the soft expirations, and AFAICT the hard
expirations aren't reported.
If multiple send SAs exist on either end, try capturing a few packets to
see which SPIs are actually being used. This doesn't require decrypting
If you decide to post any of this to the list, be sure to omit the actual
> The byte limit is 50,000 KB, though it doesn't drop until I transfer
> 200-400 MB or so within roughly 2-3 hours. It'll eventually come back
> after a few hours if I'm not able to get into the m0n0wall to delete
> the SA's, when before it would not come back under any circumstances
> without deleting the SA's.
Does "a few hours" correlate with the lifetime?
> Since it's likely the byte limit imposed by the PIX, how would you
> recommend resolving this? Up the PIX byte limit to something really
> high, or lower the lifetime maybe? Not sure what the best course of
> action would be here.
Making it work right would be best. :-)
I can see how "prefer newer" could cause out-of-order expirations of byte-
or packet-based lifetimes, although it's still not clear why this should
cause a loss of connectivity.
You could check to see if it's an issue with "prefer newer" by switching
the sysctl back. You can do it on the fly with
sysctl -w net.key.preferred_oldsa=1
though that will be undone by /etc/inc/vpn.inc on the next change to the
IPsec config (or reboot). Meanwhile, the problem with reboots would be
back, of course.