Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A most elegant TCP hole punching algorithm

robertsdotpm.github.io

Post reply on HN
Print view View original

61–70 of 111 posts

Re: A most elegant TCP hole punching algorithm

#61

Post by cperciva »

huhtenberg wrote: post #56
cperciva wrote: post #8

Earlier quoted context omitted.

RFCs may say that simultaneous connect must be allowed, but that doesn't mean that firewalls can't block it. Plenty of setups block incoming SYN,!ACK packets, and if both sides do that, the connection is never getting established.

> Plenty of setups block incoming SYN,!ACK packets Even in the presence of a conntrack entry created by an earlier outbound SYN,!ACK ? Got a source?

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.

Re: A most elegant TCP hole punching algorithm

#62

Post by [deleted] »

cperciva wrote: post #61
huhtenberg wrote: post #56

Earlier quoted context omitted.

> Plenty of setups block incoming SYN,!ACK packets Even in the presence of a conntrack entry created by an earlier outbound SYN,!ACK ? Got a source?

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.

[deleted]

Re: A most elegant TCP hole punching algorithm

#63

Post by patrakov »

aboardRat4 wrote: post #58
lxgr wrote: post #14

Does TCP hole punching actually work with common CPEs and CG-NATs? I don’t think I’ve ever seen it done successfully and have often wondered if it’s for a lack of use cases or due to its bad success rate and complexity compared to UDP hole punching. That said, I really wish there was a standardized way to do it. Some sort of explicit (or at least implicit but unambiguous) indicator to all firewalls that a connection…

The standard way to do it is called ipv6. Implementing it is probably easier than any of those RFCs

No, it isn't. Many middleboxes (including OpenWrt by default) drop unsolicited inbound TCP connections even on IPv6, and therefore the same hole-punching algorithm is needed. The hole being punched is in the stateful firewall's connection tracker, not in the NAT. Basically, both parties need to convince their router that it is an outgoing connection initiated by them, not a prohibited-by-policy incoming connection.

Re: A most elegant TCP hole punching algorithm

#64

Post by jder »

I don’t think the bucket-choosing algorithm works? The two hosts can be just on opposite sides of a bucket edge. For example if one host sees t=61 and another sees t=62, they will get different buckets despite being less than 20 seconds apart. You’ve got to check adjacent buckets within your error tolerance, not expand the bucket windows in size based on it.

Re: A most elegant TCP hole punching algorithm

#65

Post by huhtenberg »

cperciva wrote: post #61
huhtenberg wrote: post #56

Earlier quoted context omitted.

> Plenty of setups block incoming SYN,!ACK packets Even in the presence of a conntrack entry created by an earlier outbound SYN,!ACK ? Got a source?

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.

Re: A most elegant TCP hole punching algorithm

#66

Post by cperciva »

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.

for obvious reasons

What are the obvious reasons? If you're protecting a client system, you don't want to allow in any bare SYNs. (And for that matter, if you're protecting a server, you probably want to discard ill-targeted bare SYNs without consulting conntrack anyway, just as a matter of avoiding extra CPU work.)

Re: A most elegant TCP hole punching algorithm

#67

Post by gzread »

patrakov wrote: post #63
aboardRat4 wrote: post #58

Earlier quoted context omitted.

The standard way to do it is called ipv6. Implementing it is probably easier than any of those RFCs

No, it isn't. Many middleboxes (including OpenWrt by default) drop unsolicited inbound TCP connections even on IPv6, and therefore the same hole-punching algorithm is needed. The hole being punched is in the stateful firewall's connection tracker, not in the NAT. Basically, both parties need to convince their router that it is an outgoing connection initiated by them, not a prohibited-by-policy incoming connection.

All you should need is for both sides to connect to each other. Side A connecting to side B opens a hole in side A's firewall and is blocked by side B, then B connects to A, opening B's firewall and going through the already open hole in A's firewall.

It might work better with UDP but I don't think those firewalls boxes tear down the mapping immediately on getting an RST - they wait until it times out.

Re: A most elegant TCP hole punching algorithm

#68

Post by gzread »

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.

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.

Re: A most elegant TCP hole punching algorithm

#69

Post by gzread »

lxgr wrote: post #28
Veserv wrote: post #22

Earlier quoted context omitted.

It is always a mystery how people just randomly misinterpret what I write. At literally no point did I mention port mapping. I am pointing out how the problem NAT “solves” is just dynamic address configuration. They have implemented a N+K bit address where the N-bit prefix is routed and allocated using IP and the low K-bits are routed and allocated like a custom fever dream. You can just do it all the same way instea…

If I understand it correctly, you're suggesting formalizing a way to make parts of the (host-specific) port canonically part of the network-wide address, no? This still sounds like a very bad mixing of layers, even if done in a perfectly standardized and uniform way. > It is always a mystery how people just randomly misinterpret what I write. If this is intended literally and not as a general complaint: My main probl…

The original SOCKS proxy specification was something like this. You'd LD_PRELOAD a library that would make the application think it was running directly on the proxy server, and it supported both connecting outbound and listening.

Re: A most elegant TCP hole punching algorithm

#70

Post by gzread »

hdgvhicv wrote: post #34
lxgr wrote: post #31

Earlier quoted context omitted.

Firewalls aren't nearly as bad as NAT.

Basically the same thing. If you legitimately need to establish a connection then put a firewall rule in, whether that needs nat or pat is a function of your available addresses. If you are tying to work around your firewall because it isn’t yours, that’s not a legitimate use.

P2P traffic is illegitimate according to you? Like Skype calls? You think Skype should not exist? (Well it doesn't exist any more, but whatever replaced it)
Post reply on HN