Configure the IPsec pod network on OpenShift

This document explains how to configure the Internet Protocol Security (IPsec) pod’s network interface on an OpenShift Container Platform (OCP) cluster. The IPsec pod must have a kernel-visible interface on the same subnet as the Traffic Management Microkernel (TMM) pod’s server-side self-IP so the two pods can exchange IKE and ESP traffic.

On OCP clusters where the SR-IOV network node policy uses deviceType: netdevice, the IPsec pod gets a kernel-visible interface without any Virtual Function (VF) pool split. The pod attaches to the same SR-IOV network that TMM already uses — no separate network resource is required.

Before you begin

Make sure you have:

• An OCP cluster with CNF 2.4 or later installed

• SR-IOV Network Operator deployed and configured

• TMM pods running with an SR-IOV server-side interface (for example, 22.22.22.120/24)

• oc and kubectl access to the cluster with permissions to create SR-IOV network resources and Helm releases

• The IP address you want to assign to the IPsec pod (must be on the same subnet as TMM’s server-side self-IP)

  Note

  The IPsec pod’s IP address and CIDR prefix length must match the subnet used by TMM’s self-IP on the shared interface.

Verify the SR-IOV node policy

The IPsec pod reuses the same SR-IOV network resource pool that TMM uses. Verify that the SR-IOV network node policy is already configured on the cluster:

oc get sriovnetworknodepolicy -n openshift-sriov-network-operator

If the expected policy is missing, complete the base SR-IOV and TMM network setup before you continue with the IPsec configuration.

Create the SR-IOV network for IPsec

Create an SriovNetwork resource that the IPsec pod attaches to (tmm-svr-net). This resource uses the netdevice resource pool as TMM’s server-side interface, which places the IPsec pod on the same subnet as TMM.

1. Create a YAML file named sriov-ipsec-network.yaml and define the SriovNetwork resource as shown below.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: tmm-svr-net
     namespace: openshift-sriov-network-operator
   spec:
     networkNamespace: ipsec-test
     resourceName: sriovEns1f1Mlx5NetdevPolicy
     spoofChk: "off"
     trust: "on"
     capabilities: '{"mac": true, "ips": true}'
     ipam: |-
       {
         "type": "static"
       }
   

2. Create the target namespace (if it does not already exist) and apply the SR-IOV network:

   oc create ns ipsec-test
   oc apply -f sriov-ipsec-network.yaml -n openshift-sriov-network-operator
   

3. Verify the resources were created:

   oc get sriovnetwork -n openshift-sriov-network-operator
   oc get network-attachment-definition -n ipsec-test
   

Note

If tmm-svr-net already exists as part of the TMM setup, you do not need to create it again. The IPsec pod attaches to TMM’s existing server-side network — it does not require its own separate network.

Update the IPsec Helm values

• Configure the IPsec pod to attach to the SR-IOV network and assign it a static IP address on the same subnet as TMM’s server-side self-IP. Add the following to your overrides file:

  f5-ipsec:
    enabled: true
  
    ipsec:
      name: f5-ipsec
      enabled: true
  
      image:
        repository: repo.f5.com/images
  
      # SR-IOV network attachment — name must match SriovNetwork resource deployed in your cluster
      annotations:
        k8s.v1.cni.cncf.io/networks: |
          [
            {
              "name": "tmm-svr-net",
              "ips": ["10.10.10.1/24", "2001:db8::1/112"]
            }
          ]
  
      # DSSM namespace must match where dssm-f5-dssm is deployed — wrong namespace breaks HA store on restarts
      dssm:
        service: dssm-f5-dssm-sentinel.<namespace>   # replace <namespace> with actual DSSM namespace
  
      fluentbit_sidecar:
        image:
          repository: repo.f5.com/images
        fluentd: 
          host: f5-toda-fluentd.<namespace>.svc.cluster.local.   # replace <namespace> with actual fluentd namespace
  

Confirm subnet alignment

After the IPsec pod starts, verify that it has an IP address on the same subnet as TMM’s server-side interface:

Component	Expected IP (example)	Subnet
TMM internal self-IP	10.10.10.2	10.10.10.2/24
IPsec pod IP	10.10.10.1	10.10.10.1/24

Note

If the OpenShift network policy for the cluster is configured with devicetype set to vfio, a kernel-visible interface is not supported. To enable kernel-visible interface support, set devicetype to netdevice. Once this configuration is applied, configure the IPsec pod IP network on vanilla cluster. For more details, see Configure the IPsec pod network on vanilla cluster.