search

kubernetes-sigs / ip-masq-agent

Manage IP masquerade on nodes
Apache License 2.0
217 stars 70 forks source link

Multiple Connections with same source port #50

Closed davidebelloni closed 4 years ago

davidebelloni commented 4 years ago

Hi, I've some GKE clusters with ip-masq-agent, without a custom configuration, that translate connections to public IPs keeping the source port of pod connection.

In my context, where I open a lot of connections and I have an implicit egress proxy that use a REDIRECT iptables rule to be "transparent", this behaviour create issues with connections that exit from the same node and has same source pod port, because my iptables rule "translate" them with same destination and port destination.

I'm trying to setup egress proxy with TPROXY iptables rule to prevent this issue, but I ask you if it is possible to scramble source port of NAT'ed connections to prevent the problem definitively.

Thanks

fejta-bot commented 4 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

davidebelloni commented 4 years ago

/remove-lifecycle stale

varunmar commented 4 years ago

Sorry for the delay, I missed this notification entirely.

I'm not sure I understand the issue completely, so let me try to rephrase it and you can tell me where I'm wrong. You have an explicit rule to DNAT (some type of?) traffic to an explicit destination + port. Pods on that node that happen to use the same source port (but different source IPs?) are being incorrectly DNATed, because they were masqueraded before your rule saw them.

Is that a correct summary? It would be helpful if you added the rule you are using and an example of a problematic connection and what it's source/dest ip/port pairs are before and after the masq and your custom rules are applied.

If a connection is actively using the source port, the masquerade will not reuse it - so I assume the problem is not that active connections are being stomped on but that your rule relies on an explicit source port being used?

It would be helpful to see an example of the conflict. But to answer your question directly - there is a way to tell masquerade to only use some ports (--to-ports=25000-30000 for eg) but ip-masq-agent today doesn't support those options.

fejta-bot commented 4 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

fejta-bot commented 4 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

fejta-bot commented 4 years ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close

k8s-ci-robot commented 4 years ago

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/ip-masq-agent/issues/50#issuecomment-716057507): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Send feedback to sig-testing, kubernetes/test-infra and/or [fejta](https://github.com/fejta). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.