> 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.
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.
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
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?
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 > "The benefits of birthdays"
The tailscale article is about UDP, but here we are talking about TCP.
> 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
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.
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
I have separately documented the same thing happening on our work knowledgebase. TCP is always such fun.
Intuitively it doesn't sound like it would work. The program doesn't call listen() or accept() on the socket.
The comment section on it answered that: it's TCP simultaneous open.