Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I haven't read TFA, but it happened to me on an ISP which had a CGNAT, probably as a way of garbage collecting open connections. The solution was to use an application-level keepalive, which winscp and putty support.


*workaround.

The solution is for the ISP to fix their misconfigured NAT.


Taking into account they had to take extra steps to enable this "feature", they probably don't consider it to be "misconfigured", at least from their point of view.


A NAT is going to have to have a timeout, otherwise it will gradually leak and run out of ports. All protocols that operate behind NAT must implement keepalive.

The solution is IPv6. Then you don't need your ISP to maintain a stateful connection table.


I'll be pedantic: you mean that the solution is no NAT, with IPv6 being something needed to get there. Nothing stops you from NAT'ing IPv6.


> Nothing stops you from NAT'ing IPv6.

Nothing stops you from filling your car with orange juice either.


NAT'ing IPv6 works and is merely not a necessity. It could still have a purpose, It just won't be address exhaustion.

Filling your car with orange juice presumably stops it from working and is likely to cause damage, all while your parents question where things went wrong.


As proven by Microsoft in Azure's IPv6 support.


The solution is IPv6.


There is no such thing as a properly configured NAT implementation that does not have timeouts for idle sessions. Without those you’d run out of memory on your router and new sessions would be blocked.


NAT is fundamentally not the solution.


The app-level keep alive will work for a while, probably a long while, but could still fail if there are enough connections using the method and the CGNAT routed has too few source addresses to map thing to. If the router needs to find some ports to use for new connections, and there are no apparently idle connections to throw out, it has few choices:

1. Just stop making new connections until some ports are freed. That'll make people happy...

2. Kill the connections that have least recently seen activity even if they have sent/received packets within the usual timeout.

3. Kill the longest running connections that aren't from a whitelist of target ports like 80 & 443 (P2P and VPN systems will just reconnect, the user will hopefully see no more than a short blip SSH will not fair so well).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: