**What happened**:
When running "subctl diagnose firewall inter-cluster" test between clusters in azure platform and other platform, incorrect state returned.

ACM 2.5.0
Submariner 0.12.0 (Globalnet enabled)
OCP versions 4.9.25

 ✗ Checking if tunnels can be setup on the gateway node of cluster "mbabushk-sub3" 
 ✗ The tcpdump output from the sniffer pod does not include the message sent from client pod. Please check that your firewall configuration allows UDP/4505 traffic on the "mbabushk-sub3-7ptvl-worker-centralus1-vsrvt" node.

But the UDP/4505 port opened on both clusters.

**What you expected to happen**:
The test of the firewall between clusters should pass.

**How to reproduce it (as minimally and precisely as possible)**:
Deploy two clusters. One in Azure platform and one in other platform.
Run the firewall test.
It will return an error, while the configuration is correct.

**Anything else we need to know?**:
Debugging output by Sridhar (Slack thread):
==========================================================
Maxim Babushkin
Hi @multiclusternetwork-team
Have a question regarding azure platform.
I made a deployment of submariner on aws, gcp and azure platforms.
All the cloud prepare steps I made manually.
When I'm running the subctl diagnose firewall inter-cluster command and specifying the azure cluster, I get the following error:
 ✗ Checking if tunnels can be setup on the gateway node of cluster "mbabushk-sub3" 
 ✗ The tcpdump output from the sniffer pod does not include the message sent from client pod. Please check that your firewall configuration allows UDP/4505 traffic on the "mbabushk-sub3-7ptvl-worker-centralus1-vsrvt" node.
The port is open and all e2e tests are passing.
Only this check fails.
When I'm testing the firewall between aws and gcp, no issue.
It happens only when azure involved.
Is it happens because cloud prepare is not yet implemented and some check of the firewall relies on it?
Or is there any other reason?
Thanks.

Sridhar Gaddam
Hello Maxim, well if the tunnels are successfully created and since e2e is passing, I dont think there was an issue with cloud-prepare.

Sridhar Gaddam
Please share the kubeconfigs of the three clusters (in private), I can take a look and provide an update.

Maxim Babushkin
@sridharg
Thanks.
Will share in a sec.

Sridhar Gaddam
@mbabushk there is a problem while deploying the diagnose pods on the Azure cluster.

Sridhar Gaddam
For some reason, K8s running on Azure is automatically adding some volumes to the pod and this seems to be causing issues

Sridhar Gaddam
│Events:                                                                                                                                                                                                                                     │
│  Type     Reason          Age                From                                   Message                                                                                                                                                │
│  ----     ------          ----               ----                                   -------                                                                                                                                                │
│  Normal   Scheduled       <unknown>                                                 Successfully assigned default/validate-clientnvkbb to mbabushk-sub3-7ptvl-master-2                                                                     │
│  Normal   AddedInterface  24s                multus                                 Add eth0 [10.130.0.33/23] from openshift-sdn                                                                                                           │
│  Normal   Pulled          24s                kubelet, mbabushk-sub3-7ptvl-master-2  Container image "quay.io/submariner/nettest:devel" already present on machine                                                                          │
│  Normal   Created         24s                kubelet, mbabushk-sub3-7ptvl-master-2  Created container validate-client                                                                                                                      │
│  Normal   Started         24s                kubelet, mbabushk-sub3-7ptvl-master-2  Started container validate-client                                                                                                                      │
│  Warning  FailedMount     13s (x2 over 14s)  kubelet, mbabushk-sub3-7ptvl-master-2  MountVolume.SetUp failed for volume "kube-api-access-5dhqq" : [object "default"/"kube-root-ca.crt" not registered, object "default"/"openshift-service-│
│ca.crt" not registered] 

Sridhar Gaddam
This is the corresponding Pod.Spec

Sridhar Gaddam
  volumes:
  - name: kube-api-access-b7jk6
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
      - configMap:
          items:
          - key: service-ca.crt
            path: service-ca.crt
          name: openshift-service-ca.crt

Sridhar Gaddam
We do not add this to the pod, its getting auto-added by some component and because of this, the pod is not starting (hence diagnose is failing)

Sridhar Gaddam
These volumes seem to be added even on the other OCP clusters, but on Azure its failing with FailedMount error. We need to debug this further to understand why these volumes are added and if we can figure out a way to get past this issue.
==========================================================