AWS_VPC_K8S_CNI_RANDOMIZESNAT matching PODs with hostNetwork: True

[adamdunstan]

What happened:

We have an application that uses hostnetwork: true and sends traffic from a specific public port. The public port and hostNetwork: true is used because traffic is returned to the host/port. By default the CNI is SNATing the PORTS.

What you expected to happen:
Is this the expected default behaviour, I would think that the expected behavior would be that for hostNetwork: true, the set port is not modified.

The expected default behaviour when using hostNetwork: true is that the port remains unchanged.

Environment:

Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.5", GitCommit:"c285e781331a3785a7f436042c65c5641ce8a9e9", GitTreeState:"clean", BuildDate:"2022-03-16T15:58:47Z", GoVersion:"go1.17.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22+", GitVersion:"v1.22.6-eks-7d68063", GitCommit:"f24e667e49fb137336f7b064dba897beed639bad", GitTreeState:"clean", BuildDate:"2022-02-23T19:29:12Z", GoVersion:"go1.16.12", Compiler:"gc", Platform:"linux/amd64"}

amazon-k8s-cni:v1.10.2-eksbuild.1

[ec2-user@ip-192-168-99-208 ~]$ cat /etc/os-release
NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"

Linux ip-192-168-99-208.ec2.internal 5.4.181-99.354.amzn2.x86_64 #1 SMP Wed Mar 2 18:50:46 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days

[jayanthvn]

/not stale

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days

[github-actions]

Issue closed due to inactivity.

[henry-colektia]

Hi, can we reopen this? I have the exact same problem. Keeping the IP and port is important in some applications, SIP applications in my case. I thought setting hostNetwork to true would be sufficient but ran into this behavior and spent hours finding why. It should be at least documented. The docs say that pods running with hostNetwork: true IP won't be affected by SNAT, but doesnt mention that the source port would be affected.

[jdn5126]

@henry-colektia which document are you referring to? We can work on getting the documentation updated.

As for the behavior, the SNAT is implemented via iptables, so there is no distinguishing when the source pod is in the host networking namespace vs a pod networking namespace

[jdn5126]

Closing issue as this is expected behavior

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.