As testing by Oleksandr Mamenko shows, StrongSWAN 5.x in VyOS 1.2.0 does not appear to be negotiating the IKEv1 lifetime. This results in problems with platforms that do attempt to negotiate it.
IKEv1 is supposed to support lifetime negotiation (RFC2407, page 13).
To the contrary, IKEv2 excludes lifetime negotiation completely and leaves the peers to rekey when they feel like it (with some measures to reduce the likelyhood of creating duplicate SAs, such as jittering). From RFC4306:
A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of the SA is responsible for
enforcing its own lifetime policy on the SA and rekeying the SA when
necessary. If the two ends have different lifetime policies, the end
with the shorter lifetime will end up always being the one to request
However, the details of the lifetime negotiation mechanism in RFC2407 are rather open to interpretation. In particular, "complete the negotiation but use a shorter lifetime than what was offered" is a valid choice (section 4.5.4). So, from users point of view, it may be impossible to tell lack of negotiation from technically valid behaviour, but we cannot rule out the chance that StrongSWAN is misapplying IKEv2 ideas to IKEv1.
I suppose our further course of action should be:
- Upgrade StrongSWAN to the latest version (5.6.5, ours is 5.3.4).
- If the problem is still reproducible, make IKE traffic dumps with null cipher to see what's going on, then either report to StrongSWAN maintainers or attempt to fix, or both.