A most elegant TCP hole punching algorithm • Hacker News Board

Re: A most elegant TCP hole punching algorithm

#81

Post by huhtenberg » Sun, Mar 15, 2026, 7:24 PM UTC

gzread wrote: post #68

huhtenberg wrote: post #65

Earlier quoted context omitted.

Sanity checks, sure, but SYN,!ACK packets cannot be rejected before the conntrack for obvious reasons. > Plenty of setups block incoming SYN,!ACK packets Nowhere close to being "plenty". It's doable, but this is extremely niche.

Does this mean by establishing a new connection with a SYN,ACK bypasses some firewalls? I expect at least one OS out there ignores the extraneous ACK flag and proceeds to establish a new connection.

Why would it mean that?

All inbound packets are matched against existing sessions. In this case none will turn up, so the packet will go through the "new session" flow and be subject to the same filtering as a bare SYN. Look up how connection tracking works, e.g. in the Linux kernel, it's rather simple and logical.

Re: A most elegant TCP hole punching algorithm

#82

Post by andrewmcwatters » Sun, Mar 15, 2026, 7:32 PM UTC

[dead]

Re: A most elegant TCP hole punching algorithm

#83

Post by jcalvinowens » Sun, Mar 15, 2026, 7:50 PM UTC

huhtenberg wrote: post #65

cperciva wrote: post #61

Earlier quoted context omitted.

I've seen plenty of firewall rulesets over the past 25 years which only consult state after doing some initial stateless inspection. I don't have a convenient source though.

Sanity checks, sure, but SYN,!ACK packets cannot be rejected before the conntrack for obvious reasons. > Plenty of setups block incoming SYN,!ACK packets Nowhere close to being "plenty". It's doable, but this is extremely niche.

It's not uncommon with routable internal networks to only drop inbound SYN,!ACK to disallow inbound connections while permitting outbound ones, since it doesn't require connection tracking (which can be resource intensive).

I can't really imagine why you would do it for NAT'd v4 since you can't avoid the connection tracking overhead, but you certainly could, and I don't doubt OP has run into it in the wild. I've seen much weirder firewall rules :)

Re: A most elegant TCP hole punching algorithm

#84

Post by ray_v » Sun, Mar 15, 2026, 8:43 PM UTC

One thing about this get I just realized is that if the defect exists on some home networking equipment, then the defect can be leveraged in corporate network environments to disable this functionality. If the user of the algorithm (or, person using an app using it for userspace) isn't aware of the limitations, that would be super frustrating!

Re: A most elegant TCP hole punching algorithm

#85

Post by killbot5000 » Sun, Mar 15, 2026, 8:52 PM UTC

taftster wrote: post #74

abcd_f wrote: post #73

Claimed elegance is based on a very bold assumption that the NAT device preserves the source port of outbound connection. Hardly the case in even half of typical deployment cases.

I like your comment, but it seems the author acknowledged this as a caveat to the algorithm. >Many home routers try to preserve the source port in external mappings. This is a property called “equal delta mapping” – it won’t work on all routers but for our algorithm we’re sacrificing coverage for simplicity. So to what percentage is this coverage sacrificed exactly? No idea. Not as useful if the percentage is high, a…

It’s the same assumption is required for any hole punching handshake (including STUN).

> This is a property called “equal delta mapping”

FWIW I’ve worked in computer networking for 20 years and have never heard it called this. This blog is the only source that comes up when I search for that exact term. I wonder where the author got it from.

Re: A most elegant TCP hole punching algorithm

#86

Post by ray_v » Sun, Mar 15, 2026, 9:00 PM UTC

killbot5000 wrote: post #85

taftster wrote: post #74

Earlier quoted context omitted.

I like your comment, but it seems the author acknowledged this as a caveat to the algorithm. >Many home routers try to preserve the source port in external mappings. This is a property called “equal delta mapping” – it won’t work on all routers but for our algorithm we’re sacrificing coverage for simplicity. So to what percentage is this coverage sacrificed exactly? No idea. Not as useful if the percentage is high, a…

It’s the same assumption is required for any hole punching handshake (including STUN). > This is a property called “equal delta mapping” FWIW I’ve worked in computer networking for 20 years and have never heard it called this. This blog is the only source that comes up when I search for that exact term. I wonder where the author got it from.

I wonder how many new technical terms are going to be created by LLMs - not to say that this post was N necessarily written by an LLM (but, who knows!)

Re: A most elegant TCP hole punching algorithm

#87

Post by ray_v » Sun, Mar 15, 2026, 9:20 PM UTC

CamelCaseCondo wrote: post #20

sholladay wrote: post #7

This is a great algorithm! In this era where AI is eating away at how deterministic computers are, I really appreciate reading about an elegant solution to a real problem using deterministic logic.

We still live in an age of deterministic computers. It’s the software that’s become fuzzy. (And since we’re on the subject: there’s no AI)

Are you saying that "Artificial Intelligence" is just not properly named for now.we.currently use it? Feels like at least the distinction of qualifying it with the term, "LLM" is popular.

Re: A most elegant TCP hole punching algorithm

#88

Post by abcd_f » Sun, Mar 15, 2026, 10:02 PM UTC

killbot5000 wrote: post #85

taftster wrote: post #74

Earlier quoted context omitted.

I like your comment, but it seems the author acknowledged this as a caveat to the algorithm. >Many home routers try to preserve the source port in external mappings. This is a property called “equal delta mapping” – it won’t work on all routers but for our algorithm we’re sacrificing coverage for simplicity. So to what percentage is this coverage sacrificed exactly? No idea. Not as useful if the percentage is high, a…

It’s the same assumption is required for any hole punching handshake (including STUN). > This is a property called “equal delta mapping” FWIW I’ve worked in computer networking for 20 years and have never heard it called this. This blog is the only source that comes up when I search for that exact term. I wonder where the author got it from.

> It’s the same assumption is required for any hole punching handshake (including STUN).

This is incorrect.

Hole punching requires being able to predict external port. That's it. If the port remains the same, it certainly simplifies things, but ports going up (or down) by 1 (or 2, or 5) with each new mapping is quite common, trivial to detect and to punch through.

Re: A most elegant TCP hole punching algorithm

#89

Post by K0IN » Sun, Mar 15, 2026, 10:14 PM UTC

abcd_f wrote: post #73

Claimed elegance is based on a very bold assumption that the NAT device preserves the source port of outbound connection. Hardly the case in even half of typical deployment cases.

i was also thinking about this, what keeps you from just using a (predefined) random port (or 10)?

Re: A most elegant TCP hole punching algorithm

#90

Post by ranger_danger » Sun, Mar 15, 2026, 11:03 PM UTC

abcd_f wrote: post #73

Claimed elegance is based on a very bold assumption that the NAT device preserves the source port of outbound connection. Hardly the case in even half of typical deployment cases.

Can't both sides just keep trying different ports until they get lucky? There's not that many of them, and even if it takes several minutes to get a match, that's better than nothing at all.