"nat_enabled" field needs to be anaylse

[nikitarm1611]

Open shift UI usable capcity shows 0GB .We wanted to understand how submariner nad field is working here .because we have 2 site pods where we seeing IP are getting changed.
We have a usecase where we need communication between a set of pods across two clusters for which we are using submariner. We have noticed that the communication between the pods is failing because of the source address restrictions, the pods on each site will accept the IP address of pods of other site only. But we are seeing that there is some kind of source NAT happening which is translating the IP address of pods on site1 with a different set of IP while sending traffic to site2 pods. When we investigated we found out that in submariner yamls there is a field nat_enabled set to true and the IP addresses that are of concern listed in status. We would like to understand the significance of this fields and if we are allowed to change them. End goal is to make the communication work across clusters.
We need submariner team to review it

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

⚠️ Possible Duplicate Issue

• "nat_enabled" field needs to be anaylse #3799

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[BhavaniYalamanchili]

Hi @dfarrell07 @yboaron @tpantelis
We have this issue to be fixed as a priority

We use the commands to configure the Submariner on the clusters

/root/.local/bin/subctl deploy-broker --operator-debug --kubeconfig=/connection/kube-config/71a5f5abfc/kubeconfig 

/root/.local/bin/subctl join --kubeconfig=/connection/kube-config/71a5f5abfc/kubeconfig --operator-debug --pod-debug --clusterid=site1 broker-info.subm

/root/.local/bin/subctl  join --kubeconfig=/tmp/local-kubeconfig --operator-debug --pod-debug --clusterid=site2 broker-info.subm

So here are the queries we have

1. With the above commands, what is the default behaviour with NAT, I mean, will Submariner enable the NAT automatically?
2. What is the purpose of nat_enabled: true on the submariner yaml
3. What are the requirements for the pods to have when they need to communicate between the sites? I means will the pods get the communication path automatically? Is there any debug/troubleshooting step to verify the Submariner path?

[skitt]

We have this issue to be fixed as a priority

It may be a priority for you but you can’t decide what’s a priority for the Submariner team.

You need to provide a lot more information for any of this to be actionable. You’re asking for help in solving a problem, but you haven’t explained in detail what the problem actually is, and what you’ve already tried doing to fix it.

Have you read the NAT traversal documentation? It describes nat_enabled (as natEnabled) and includes a complete flowchart for the IP selection algorithm.

[yboaron]

+1 with Stephen's points—please review the NAT-T documentation for context.

We need to clarify a few things here,

A. Environment details: are you using GlobalNet? Please provide the output of subctl gather and subctl verify (specifically for datapath tests).

B. Submariner encapsulation Logic:
Submariner encapsulates pod packets within IPSec or VXLAN, NAT-T settings apply only to these outer IP packets. Therefore, your NAT configuration should not modify the inner pod packet IP addresses.

C. Also, there's a known pod IP SNAT issue involving OVN-K CNI on specific OCP versions. Please verify your current versions against the Red Hat ACM Release Notes to see if this affects you.

[BhavaniYalamanchili]

@skitt, I am just saying in what kind of urgency state we are in. I am not deciding the priority for the submariner team, I know we don't have that kind of facility for the users, otherwise labels sections would be open for us to set the priority in some other way.

Due to security reasons, we are unable to upload the submariner logs.
I will have a word with my team and get back with a proper explanation.

Thanks @skitt, @yboaron We will go through the links and get back

[yboaron]

@BhavaniYalamanchili Any news on this issue?

[BhavaniYalamanchili]

Hi @yboaron

This is the description of the exact issue:

We have submariner installed with the below commands

/root/.local/bin/subctl deploy-broker --operator-debug --kubeconfig=<kubeconfig_file_path>
/root/.local/bin/subctl diagnose all --kubeconfig /tmp/local-kubeconfig
/root/.local/bin/subctl diagnose all --kubeconfig <remote_site_kubeconfig_path>

So no, we are not using the GlobalNet

We are able to see that all is green in submariner subctl show all and diagnose all command outputs

The issue is that we have some pods(workloads) in a namespace, and now those workloads are unreachable from and to another site, data is not being transferred/exchanged

And the OCP versions on the racks are 4.18

Queries:

1. Do we have any effect on the submariner if proxy is present on the clusters? is there any difference in having proxy and not having proxy?

2. We have a query: what if we change the nat_enabled from true to false ? What will be the effects?

[yboaron]

Please provide the output of :

• subctl gather from both clusters
• subctl verify --context cluster1 --tocontext cluster2 --only connectivity --verbose

[BhavaniYalamanchili]

@yboaron We don't have context files, we only have kubeconfig config, can we use --kubeconfig instead of --context

[yboaron]

subctl gather works with --kubeconfig, but subctl verify needs two contexts to run verification

you can merge your kubeconfigs (export KUBECONFIG=path1:path2),
check with kubectl config get-contexts context names.
then use those names in subctl verify --context <context_cluster1> --tocontext <context_cluster2> --only connectivity --verbose