Pods scheduled on certain worker nodes remain in the ContainerCreating state and do not proceed to Running. This behavior is resolved only after restarting the ipsec.service on the affected nodes.

OCP Version 4.14

Affected Component

ipsec.service (Libreswan) – used by ovn-ipsec

Steps to Reproduce

1. Deploy pods to nodes where ovn-ipsec is enabled.

1. Observe that pods get stuck in ContainerCreating state.

1. Check the status of ipsec.service on the affected nodes – service appears active.

1. Manually restart ipsec.service.

1. Pods transition to Running immediately after the restart.

Observed Behavior

• ipsec.service is active but seems to be in a stale state.

• Restarting the service restores functionality and allows pod creation to proceed.

• Logs from pluto daemon (/usr/libexec/ipsec/pluto) contain repeated messages:

netlink_expire got message with length 116 < 232 bytes; ignore message
packet from 100.110.192.40:500: responding to IKE_SA_INIT (34) message with unencrypted notification NO_PROPOSAL_CHOSEN

Expected Behavior

Pods should be scheduled and run without requiring manual intervention with ipsec.service.

Service Status Example

● ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
Loaded: loaded (/usr/lib/systemd/system/ipsec.service; enabled; preset: disabled)
Active: active (running) since Tue 2025-06-10 11:17:12 UTC
Main PID: 1326903 (pluto)
Status: "Startup completed."

Impact

• Blocks application scheduling.

• Manual intervention required to restart the service.

• Affects cluster reliability and pod availability when using OVN with IPsec.

Temporary Workaround

Manually restart the ipsec.service on affected nodes:

sudo systemctl restart ipsec.service