Add Support for SNAT Fixed Port Ranges #3175
Open
+274
−9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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