Skip to main content

Illumio Install, Configure, and Upgrade Guide 25.4 (SaaS)

Known Limitations

The known limitations in this release are:

  • Kube-proxy mode set to IPVS is currently not supported.

  • If a C-VEN on a server hosting containers is paired directly into the Enforced policy state, other nodes may lose connectivity with the master node until policy is synchronized across all the nodes.

  • Pods which run on the host network stack (inherit the host IP address) are not reported to the PCE. Any rules written for the host will also be inherited by any hostNetworked Pods on the host.

  • If you are using an external load balancer, the policy configuration will be dependent on the type of the load balancer used.

  • Kubernetes uses NAT tables, which depend on traffic being tracked and stateful. Therefore, it is not recommended to use stateless rules.

  • If a Kubernetes service has both port 1234/TCP and port 2345/UDP configured, a rule configured with the Pod as source and the virtual service as Provider will open up both ports 1234/TCP and 2345/TCP, and 1234/UDP and 2345/UDP on the Pod's firewall (outbound rule).

    In case of a Kubernetes service configured with a port and targetPort statement in the manifest file as shown in the example below:

    apiVersion: v1
    kind: Service
    metadata:
      name: web-frontend-svc
      namespace: app1
      labels:
        app: app1
        tier: web-frontend
      annotations:
        com.illumio.role: Web
    spec:
      type: ClusterIP
      ports:
      - port: 8080
        targetPort: 80
        protocol: TCP
      - port: 8081
        targetPort: 81
        protocol: UDP
      selector:
        app: app1
        tier: web-frontend

    This configuration is supported with Illumio Core. In this case, only the port number associated to the port statement will show this issue, the port number associated to the targetPort statement will not show this issue and will use the protocol specified in the Service yaml file.

  • Services of the type NodePort cannot be enforced in an Openshift cluster with OVN.

    In OpenShift clusters using OVN CNI, NodePort traffic routes through a virtualized network infrastructure comprising OVS routers, switches, and load balancers. Unlike traditional CNIs like Calico, where traffic passes through the host’s IP stack and is subject to DNAT and filtering, OVN handles NodePort traffic at the virtual network layer. This means traffic reaches the target pod without traversing the host workload’s IP stack, complicating visibility and enforcement.

    Because NodePort traffic in OVN bypasses the host IP stack, Illumio cannot natively observe or enforce policies on it. The only observable point is at the pod level, where traffic appears to originate from the Gateway router IP (e.g., 100.64.x.x), obscuring the original source. This lack of visibility makes it difficult to apply precise security rules, as policies must allow traffic from all Gateway router IPs, potentially exposing the pod to unintended sources.