-
Notifications
You must be signed in to change notification settings - Fork 782
Add Support for SNAT Fixed Port Ranges #3175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Add Support for SNAT Fixed Port Ranges #3175
Conversation
68c50d1
to
9ed428a
Compare
9ed428a
to
9e5f67a
Compare
Hi @yash97 I was wondering if there's anything else needed from me here. Sorry to bother if the team is just busy, I just want to make sure nothing is blocked on me 😅 |
This pull request 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 |
Pull request closed due to inactivity. |
@ethan-gallant |
No worries, I imagine y'all are quite busy. I believe it is waiting for approval for checks but happy to address any feedback in the meantime. :) |
Any update here @jaydeokar ? |
What type of PR is this?
feature
improvement
Which issue does this PR fix?:
#3174
What does this PR do / Why do we need it?:
This PR adds functionality to exclude specific port ranges from randomized SNAT when using --randomize-fully. This is essential for maintaining compatibility with protocols that require predictable NAT behavior while still benefiting from randomized SNAT for general traffic. Several critical protocols like STUN, ICE, UDP hole punching, and cryptocurrency wallet P2P discovery rely on predictable port mapping to function correctly.
Testing done on this change:
Manually tested on EKS with STUN
With changes (
AWS_VPC_K8S_CNI_SNAT_FIXED_PORTS=3478-3479,19302
):Test STUN in a pod with pystun3
Run TCPDump on the node shows the expected predictable source port
Without changes:
Test STUN ports in a pod with pystun3
TCP Dump on the node shows a randomized source port
Will this PR introduce any new dependencies?:
No, this feature will be implemented using existing iptables functionality.
Will this break upgrades or downgrades? Has updating a running cluster been tested?:
No, this change should not break upgrades or downgrades. The default behavior (full randomization) will remain unchanged unless explicitly configured otherwise.
Does this change require updates to the CNI daemonset config files to work?:
Yes, the CNI config will need to be updated to specify excluded port ranges. This can be done via kubectl patch.
Does this PR introduce any user-facing change?:
Yes