On Tue, 9 Oct 2018, Whit Blauvelt wrote:
We're running IPsec from libreswan-3.25 to Cisco ASAs in 2 locations, each with multiple subnets on each side, and it's generally been solid. However one of the tunnels got into trouble today, so restarted IPsec, and then the other one had trouble on several subnets. Several subsequent restarts (from this end) also produced incomplete results. It took stopping IPsec, and leaving it stopped for a full minute, to get a good connection across all subnets on restarting it.
Rekeying support got extended and improved, so please tryt 3.27. We do know there is at least one interop issue left that we see on Cisco, so I'm not guaranteeing your issue will be resolved.
- Is the need for a timeout for a dependable reconnection real here, or am I seeing a correlation where the reality is random?
To avoid confusion and to avoid both ends racing to establish, it is good to wait a few seocnds. Ideally, check if the remote end has re-initiated already back to you. That is, if you have auto=start and the remote sends you a delete, you will bring down the connection and automatically start a fresh initialization attempt.
- If the timeout makes sense, what's the rule of thumb for how long it should be?
2-5 seconds should be enough.
- When one subnet out of a half-dozen isn't returning pings, is there a way to goose that single subnet without cycling the whole of IPsec off and on?
If you use seperate conns, use ipsec auto --replace conn and --up conn. If you use leftsubnetS= and rightsubnetS= it is a little tricker. You could see what the instantiated name is (eg conn-2x3) and only replace/up that one, but the numbers here depend on which ones established first and that will be a race so hard to script. Paul _______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
