-
Notifications
You must be signed in to change notification settings - Fork 777
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
Connections initiated by Pods failing often due to ephemeral port mismatch #3909
Comments
+1 We faced this issue in AWS enviourment today and took really long to figure this out that it wasn't using defualt ephemeral ports |
+1 |
Hi @sanjeevpandey19 @b44rawat, MicroK8s is not doing anything in particular for this issue, but I'm also a bit out my depth about the specifics here. MicroK8s is not messing with this configs in any way, so probably something to discuss/raise with Calico? You might be able to get more help there. |
Ok @neoaggelos thanks for the reply, i will check if i get something related to this which might be causing it |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Summary
TCP and UDP connections initiated by Pods time out/fail often (~50% of time). I tracked this network "instability" to unexpected ephemeral ports used, not matching the OS ephemeral port range and the external firewall configuration.
IOW, despite the OS having:
...the containers were using source ports in a much wider range (>1024? >0?)
I'm still unclear of is how can the (S)NAT component be configured to use a source port range per the OS
syctl
. I did not find a relevant setting in the general CNI settings or in the calico portmap docs.I verified there are no
iptables
rules doing NATWhat Should Happen Instead?
Connections should succeed all the time.
Reproduction Steps
With fexternal irewall only allowing syn-ack packets to ephemeral ports in the system (> 32768).
From a pod, run
curl 142.250.184.238
(an IP address of google.com). From the outside runtcpdump
to confirm that the source ports used by the connections are sometimes failing outside of the ephemeral port range:You can see above the source ports are
{13686, 2545, 10702, 61052}
- i.e. not within the32768 60999
range.Introspection Report
(the tar.gz includes too much private data for me to be comfortable sharing it)
Can you suggest a fix?
Update (external) firewall rules to allow a wider range of source ports (>1024)
Are you interested in contributing with a fix?
Yes
The text was updated successfully, but these errors were encountered: