3 ms·

TCP Client Self-Connect (2013)

68 points by Bogdanp 1y ago

Retr0id 1y ago
Can confirm that it still works in 2025, and also via netcat. I wonder if it's also theoretically possible for a pair of clients to connect to each other like this?
- bmenrigh 1y ago
  Yeah a pair of clients can via “tcp simultaneous open” but you’ll need to arrange for each client to know about the source port of the other. So bypass the usual ephemeral port choice made by the OS. And it’s still highly sensitive to timing.
- LeoPanthera 1y ago
  The tailscale client does this trick to force its way through NAT-to-NAT connections. "How NAT traversal works" - https://tailscale.com/blog/how-nat-traversal-works https://tailscale.com/blog/how-nat-traversal-works > "The benefits of birthdays"
  - fenesiistvan 1y ago
    The tailscale article is about UDP, but here we are talking about TCP.
- dilyevsky 1y ago
  > I wonder if it's also theoretically possible for a pair of clients to connect to each other like this? RFC793 actually specifically calls this out as one of the supported ways of two endpoints establishing a TCP connection[0]. The fact that it works on the same host via src port collision is just a happy accident. [0] - https://www.rfc-editor.org/rfc/rfc793.html#section-3.4 https://www.rfc-editor.org/rfc/rfc793.html#section-3.4
millipede 1y ago
Intuitively it doesn't sound like it would work. The program doesn't call listen() or accept() on the socket.
- j16sdiz 1y ago
  The comment section on it answered that: it's TCP simultaneous open.
deleted 1y ago
[deleted]
suprjami 1y ago
I have separately documented the same thing happening on our work knowledgebase. TCP is always such fun.
phoenix_x 1y ago
Hmm it is not working for MacOS :( I understand that linux and macos network stacks differ. However when I ran the test it and observed the network via wireshark, it seems that my machine does not send a request containing the same source port as the destination port. It just skips it, but anyway MacOS seems to have the same increasing sequential port behavior

68 points by Bogdanp 1y ago

Can confirm that it still works in 2025, and also via netcat. I wonder if it's also theoretically possible for a pair of clients to connect to each other like this?

bmenrigh 1y ago
Yeah a pair of clients can via “tcp simultaneous open” but you’ll need to arrange for each client to know about the source port of the other. So bypass the usual ephemeral port choice made by the OS. And it’s still highly sensitive to timing.
LeoPanthera 1y ago
The tailscale client does this trick to force its way through NAT-to-NAT connections. "How NAT traversal works" - https://tailscale.com/blog/how-nat-traversal-works https://tailscale.com/blog/how-nat-traversal-works > "The benefits of birthdays"
- fenesiistvan 1y ago
  The tailscale article is about UDP, but here we are talking about TCP.
dilyevsky 1y ago
> I wonder if it's also theoretically possible for a pair of clients to connect to each other like this? RFC793 actually specifically calls this out as one of the supported ways of two endpoints establishing a TCP connection[0]. The fact that it works on the same host via src port collision is just a happy accident. [0] - https://www.rfc-editor.org/rfc/rfc793.html#section-3.4 https://www.rfc-editor.org/rfc/rfc793.html#section-3.4

millipede 1y ago

Intuitively it doesn't sound like it would work. The program doesn't call listen() or accept() on the socket.

j16sdiz 1y ago
The comment section on it answered that: it's TCP simultaneous open.

deleted 1y ago

[deleted]

suprjami 1y ago

I have separately documented the same thing happening on our work knowledgebase. TCP is always such fun.

phoenix_x 1y ago

Hmm it is not working for MacOS :( I understand that linux and macos network stacks differ. However when I ran the test it and observed the network via wireshark, it seems that my machine does not send a request containing the same source port as the destination port. It just skips it, but anyway MacOS seems to have the same increasing sequential port behavior