IPTables incorrectly adds an established connection as a connecting connection in conntrack

[hbhasker]

Description

https://github.com/google/gvisor/blob/81f284f9d4af4170c86ad182e2f6f2cc9b3c565a/pkg/tcpip/stack/conntrack.go#L161 incorrectly is initializing the TCB without checking if the incoming segment has a SYN.

See: https://github.com/google/gvisor/blob/108410638aa8480e82933870ba8279133f543d2b/pkg/tcpip/transport/tcpconntrack/tcp_conntrack.go#L70 which expects the header to be the SYN header.

This means that a connection that wasn't tracked from the start would end up being tracked in a connecting state and never transition out. So if a rule is installed when connections are already active then conntrack will treat all such connections as connecting and expire them after sometime as they will never reach ESTABLISHED state due to no handshake packets being exchanged.

https://github.com/google/gvisor/blob/108410638aa8480e82933870ba8279133f543d2b/pkg/tcpip/transport/tcpconntrack/tcp_conntrack.go#L172

Ideally such connections are inserted as a NoOp and never NATed. Since they can't safely be NATed without knowing the handshake options etc. We should check what Linux does for such connections and do something similar.

Steps to reproduce

No response

runsc version

No response

docker version (if using docker)

No response

uname

No response

kubectl (if using Kubernetes)

No response

repo state (if built from source)

No response

runsc debug logs (if available)

No response

[hbhasker]

@kevinGC is there anything else left to do here?

[kevinGC]

Yeah, I think this is unresolved. Started, then forgotten during leave. Will pick it back up.

[github-actions[bot]]

A friendly reminder that this issue had no activity for 120 days.

[github-actions[bot]]

This issue has been closed due to lack of activity.