Ingress Node Firewall Operator version 4.18 is incorrectly installed on OpenShift 4.17 or older clusters

Solution Verified - Updated 6 Mar 2026

Environment

Red Hat OpenShift Container Platform (RHOCP)
- < 4.18
Ingress Node Firewall Operator 4.18

Issue

After a catalog update, the Ingress Node Firewall Operator may have been upgraded to version 4.18, which is not supported on OpenShift Container Platform (OCP) versions 4.17 or older clusters.

This article covers the specific remediation for the Ingress Node Firewall Operator. For the general issue affecting multiple operators, refer to Red Hat Operator has version higher than the cluster version.

Check if the Ingress Node Firewall Operator is upgraded (4.18)

To find the ClusterServiceVersion (CSV), Subscription and InstallPlan of the ingress-node-firewall with the 4.18 version, the following command should be used in the openshift-ingress-node-firewall namespace:

$ oc get csv,sub,installplan -n openshift-ingress-node-firewall
NAME                                                                                    DISPLAY                          VERSION               REPLACES                                     PHASE
clusterserviceversion.operators.coreos.com/ingress-node-firewall.v4.18.0-202601302238   Ingress Node Firewall Operator   4.18.0-202601302238   ingress-node-firewall.v4.17.0-202602090843   Succeeded

NAME                                                      PACKAGE                 SOURCE                 CHANNEL
subscription.operators.coreos.com/ingress-node-firewall   ingress-node-firewall   redhat-operators   stable

NAME                                             CSV                                          APPROVAL    APPROVED
installplan.operators.coreos.com/install-8lmds   ingress-node-firewall.v4.18.0-202601302238   Automatic   true
installplan.operators.coreos.com/install-pqlwh   ingress-node-firewall.v4.17.0-202602090843   Automatic   true

The version of the operator is listed under the VERSION column of the CSV. If the operator version is the same as the version of the current OpenShift cluster, the operator was not upgraded and no further steps are needed. If the version of the CSV is 4.18.*, then the downgrade process needs to be followed.

If a IngressNodeFirewallConfig object is created then the ingress-node-firewall daemon pods will be running in the openshift-ingress-node-firewall namespace along with the ingress node firewall operator (controller-manager) pod.

$ oc -n openshift-ingress-node-firewall get ingressnodefirewallconfig
NAME                        AGE
ingressnodefirewallconfig   32s

$ oc -n openshift-ingress-node-firewall get pods
NAME                                                        READY   STATUS    RESTARTS   AGE
ingress-node-firewall-controller-manager-6b6f89dfdf-qxqs5   2/2     Running   0          5m52s
ingress-node-firewall-daemon-5dfsf                          3/3     Running   0          69s
ingress-node-firewall-daemon-l4jvk                          3/3     Running   0          69s
ingress-node-firewall-daemon-s5mkh                          3/3     Running   0          69s

Resolution

Steps to downgrade the Ingress Node Firewall Operator to the supported version

CAUTION: This procedure involves removal and then addition of resources:

When the 4.18 CSV is removed from the cluster, any resources owned by the CSV will be deleted, including the ingress-node-firewall-controller-manager Deployment, ServiceAccounts, Roles, and RoleBindings. The ingress-node-firewall-daemon DaemonSet and its corresponding pods will remain running, along with any IngressNodeFirewall objects that were created.
After recreating the original version subscription, all resources (ingress-node-firewall-controller-manager Deployment, Secrets, Roles, RoleBindings, and the ingress-node-firewall-daemon DaemonSet) will be recreated. This recreation will bring all components back into a working state, including the ingress-node-firewall-controller-manager and the ingress-node-firewall-daemon pods.
After the completion of the process, if the IngressNodeFirewall rules do not work correctly, then the IngressNodeFirewall and IngressNodeFirewallConfig objects should be recreated to fix the issue. Thus, it is important to backup IngressNodeFirewall and IngressNodeFirewallConfig objects before starting the downgrade process.

First the IngressNodeFirewall and IngressNodeFirewallConfig objects should be backed up. The following commands can be used for the backup:

$ oc -n openshift-ingress-node-firewall get ingressnodefirewall -oyaml > ingressnodefirewall.yaml

$ oc -n openshift-ingress-node-firewall get ingressnodefirewallconfig -oyaml > ingressnodefirewallconfig.yaml

For downgrading the operator to the same version of the OpenShift cluster, the ClusterServiceVersion (CSV) and Subscription corresponding to the Ingress Node Firewall Operator should be deleted first. For the above example, the CSV_NAME is ingress-node-firewall.v4.18.0-202601302238. The CSV can be deleted using the following command:

$ oc -n openshift-ingress-node-firewall delete csv <CSV_NAME>
clusterserviceversion.operators.coreos.com "<CSV_NAME>" deleted

Next the operator subscription should be deleted the using command:

$ oc -n openshift-ingress-node-firewall delete subscription ingress-node-firewall
subscription.operators.coreos.com "ingress-node-firewall" deleted

The ingress-node-firewall-controller-manager pod will be deleted but the ingress-node-firewall-daemon pods will be still running.

$ oc -n openshift-ingress-node-firewall get pods
NAME                                 READY   STATUS    RESTARTS   AGE
ingress-node-firewall-daemon-8dl7w   3/3     Running   0          14m
ingress-node-firewall-daemon-s2s7g   3/3     Running   0          14m
ingress-node-firewall-daemon-zz975   3/3     Running   0          14m

Next to install the operator of the correct version, the corresponding subscription should be created. It is recommended that the installPlanApproval of the subscription be set to Manual mode. Following command can be used to create the subscription:

$ oc apply -f - <<EOF
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
 name: ingress-node-firewall
 namespace: openshift-ingress-node-firewall
spec:
 channel: stable
 installPlanApproval: Manual
 name: ingress-node-firewall
 source: redhat-operators
 sourceNamespace: openshift-marketplace
EOF
subscription.operators.coreos.com/ingress-node-firewall created

Since the installPlannApproval is set to Manual, it needs to be approved manually.

First the current installPlan name should be fetched:

$ oc get installplan -n openshift-ingress-node-firewall
NAME            CSV                                          APPROVAL   APPROVED
<INSTALL_PLAN>   ingress-node-firewall.v<VERSION>   Manual     false

Then, the fetched INSTALL_PLAN name should be used to approve the InstallPlan by patching it:

$ oc patch installplan -n openshift-ingress-node-firewall <INSTALL_PLAN> --patch '{"spec":{"approved":true}}' --type=merge
installplan.operators.coreos.com/<INSTALL_PLAN> patched

The approval status of the InstallPlan should now show as true:

$ oc get installplan -n openshift-ingress-node-firewall
NAME            CSV                                          APPROVAL   APPROVED
<INSTALL_PLAN>   ingress-node-firewall.v<VERSION>   Manual     true

Testing the new subscription is working

The newly created CSV should have the VERSION same as the version of the cluster, i.e. if the OpenShift cluster is 4.17, then the CSV version should also be 4.17.*. To check this the following command can be used:

$ oc -n openshift-ingress-node-firewall get csv
NAME                                         DISPLAY                          VERSION               REPLACES   PHASE
ingress-node-firewall.v4.17.0-202602090843   Ingress Node Firewall Operator   4.17.0-202602090843              Succeeded

The ingress-node-firewall-controller-manager pod also will be deployed and running:

$ oc -n openshift-ingress-node-firewall get pods
NAME                                                        READY   STATUS    RESTARTS   AGE
ingress-node-firewall-controller-manager-6998965745-p7mvd   2/2     Running   0          98s
ingress-node-firewall-daemon-2rrh2                          3/3     Running   0          79s
ingress-node-firewall-daemon-gqlbh                          3/3     Running   0          78s
ingress-node-firewall-daemon-mk2tf                          3/3     Running   0          81s

Note: Post the installation of the operator of the correct version, it should be tested to check whether the IngressNodeFirewall rules are correctly applied or not. If the rules are not working as expected, then the IngressNodeFirewall objects should be deleted first. Once those are deleted then the IngressNodeFirewallConfig should also be deleted which in turn will remove the ingress-node-firewall-daemon pods. Then the objects should again be recreated from the backup that was taken before the start of the downgrade process, first the IngressNodeFirewallConfig object and then the IngressNodeFirewall objects.

Root Cause

For several hours on February 3, 2026, Red Hat released 4.18 Red Hat Operators catalog content into 4.12-4.17 clusters.

For more information, including Diagnostic Steps, please refer to Red Hat Operator has version higher than the cluster version.

Diagnostic Steps

For more information, including Diagnostic Steps, please refer to Red Hat Operator has version higher than the cluster version.

SBR

Shift Networking

Product(s)

Red Hat OpenShift Container Platform

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.