Strongswan not respondong to IKE messages on port 500 after establishing a connection about strongswan HOT 4 CLOSED

You refer to rekeyings, but if you see IKE_SA_INITs, then those are not rekeyings but possibly reauthentications or simply reestablishments. If strongSwan initiates reauthentications, it will use the previous IPs and ports (i.e. usually 4500). Only if that fails and the SAs have to be reestablished, will it re-resolve addresses and revert back to the original ports (usually 500).

You need to have a closer look at the exchanged packets. Packets sent to port 4500 have to be prefixed with a non-ESP marker (4 zero bytes after the UDP header), if that's not the case, they won't reach the IKE daemon. Likewise, packets sent to port 500 should not have such a marker.

from strongswan.

I've checked the packets now, Strongswan definitely does include the 4 zero bytes non-ESP marker after the UDP header when sending on 4500. And the other endpoint doesn't have the non-ESP marker in its port 500 packets.

Packet 1 (Strongswan to Cisco, non-ESP marker present on 4500):

Packet 3 (Cisco to Strongswan, non-ESP marker not present on 500):

from strongswan.

Try checking whether anything is logged about these packets (maybe increase the log level for net). Also make sure there is only a single IKE daemon running and that no firewall rules (e.g. installed by an updown script) block the packets.

from strongswan.

I wasn't able to get any more lower level information about these packets. The tunnel was reverted back to IKEv1 and it has been stable since. Would have liked to get to the bottom of the problem with IKEv2 but looks to be related to Cisco's handling of IKE on 4500 and not something Strongswan was doing.

from strongswan.