Possible bug in 21.02 ikev2 and rekey

[jgraham5481]

Hi,
I have an SG-3100 at my house and an XG-7100 at my datacenter. The 7100 is connected to a test environment so I decided to update to 21.02 and at home, I have all the balls in the world and always go to the latest, greatest. Anyways, I noticed that the tunnel to this guy, (VTI) would stay up, but stop passing traffic after a while. Restarting the IPSEC service would allow it to pass traffic again. I have an identical (crypto and settings wise) tunnel to another XG-7100 (from the 3100 at home) in my production network, at the datacenter, but this 7100 runs 2.4.1 and it stayed up solid. When going to the IPSEC status page, I noticed that when comparing the two tunnels, the pair that is 21.02 on both sides had "Reauth: Disabled", where as the tunnel that was 21.02 <-> 2.4.1 has a value in seconds, incrementing down. If on the 21.02 pair, I set a value, even on one side of .9 of lifetime for reauth, traffic never stops. I think we may want to ensure that when the value for reauth is null, that it sets it for .9 of lifetime. Otherwise, if someone updates both sides and they use VTI (Might happen on legacy IPSEC too, but I'm not running those). Below is snippet of what the status looks like when when traffic always passes. Maybe this helps other folks.

[LamaZ]

@jgraham5481 This solved my issue where I was seeing something like:

[ESP] ESP sequence number verification failed:

in the Android Strongswan app, but now I can't recreate the error log in the app by removing the Reauth Time. I wanted to recreate the log so I can add it here for accuracy. That's what I get for not even taking screenshot.

I added a value to "Reauth Time", then I removed it. Now Android Strongswan app doesn't show ESP errors in 21.02 after I changed P2 hash to SHA384. More on the hash issue here.

Thanks again!

-LamaZ