pfSense

Found a scenario where this is replicable with PPPoE.

1) setup IPsec bound to a PPPoE WAN, with no keepalive defined and nothing running in the background that will trigger the connection
2) bring the system up on a clean boot, go to Status>Interfaces and disconnect the PPPoE. Then reconnect it.
3) initiate some traffic that triggers the IPsec connection to come up.

It'll end up with logs along the lines of the following:

Feb 16 20:43:23    charon: 11[IKE] giving up after 5 retransmits
Feb 16 20:43:23    charon: 11[IKE] <con3000|2> giving up after 5 retransmits
Feb 16 20:43:23    charon: 12[CFG] ignoring acquire, connection attempt pending
Feb 16 20:43:23    charon: 12[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:43:10    charon: 09[CFG] ignoring acquire, connection attempt pending
Feb 16 20:43:10    charon: 12[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:43:01    charon: 12[CFG] ignoring acquire, connection attempt pending
Feb 16 20:43:01    charon: 09[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:42:48    charon: 09[CFG] ignoring acquire, connection attempt pending
Feb 16 20:42:48    charon: 12[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:42:38    charon: 12[CFG] ignoring acquire, connection attempt pending
Feb 16 20:42:38    charon: 09[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:42:26    charon: 09[CFG] ignoring acquire, connection attempt pending
Feb 16 20:42:26    charon: 12[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:42:16    charon: 12[CFG] ignoring acquire, connection attempt pending
Feb 16 20:42:16    charon: 09[KNL] creating acquire job for policy 203.0.113.77/32|/0 === 100.64.25.22/32|/0 with reqid {3}
Feb 16 20:42:07    charon: 09[NET] sending packet: from 203.0.113.77[500] to 100.64.25.22[500] (200 bytes)

and fail to come up. Stop and start strongswan and it comes up right away. If the connection is up before you disconnect PPPoE, whether via Status>Interfaces or by forcing a reconnect at the PPPoE server side, it picks up immediately as soon as the connection is back up.

In this specific circumstance, strongswan shows it's seeing the interface events.

Feb 16 20:34:25 pfs22-ipsectest4 charon: 11[KNL] 203.0.113.77 disappeared from pppoe1
Feb 16 20:34:27 pfs22-ipsectest4 charon: 11[KNL] interface pppoe1 disappeared
Feb 16 20:34:33 pfs22-ipsectest4 charon: 10[KNL] interface pppoe1 appeared
Feb 16 20:34:33 pfs22-ipsectest4 charon: 10[KNL] 203.0.113.77 appeared on pppoe1
Feb 16 20:34:33 pfs22-ipsectest4 charon: 10[KNL] fe80::250:56ff:fea7:7031 appeared on pppoe1

and 'ipsec statusall' shows the pppoe1 IP missing from "Listening IP addresses".

Listening IP addresses:
  198.51.100.77

only the other WAN where this system has an IPsec connection bound. A reload doesn't make the IP come back. A full restart brings it back to normal.

Listening IP addresses:
  198.51.100.77
  203.0.113.77

Updated subject should be accurate of specific issue. Removing interfaces_use from strongswan.conf makes the problem go away. Though 'ipsec statusall' still shows the IP missing under "Listening IP addresses", it works fine.

there are issues in strongswan with the interfaces_use option. For now, we'll disable it by default, and add a checkbox to Advanced to enable it should there be scenarios we're unaware of where this is desirable.

fixed