For the last few days, connections originating behind my LAN's NAT have been having issues completing the TCP handshake (i.e. web pages only load after hitting F5 a few times, network applications sometimes timeout when starting, etc.). After a TCP connection is estabilished, everything works fine.

My network configuration is ~20 machines behind an EdgeOS router, which masquerades internal addresses to my ISP's PPPoE endpoint. No updates or configuration changes have been made recently (last 6 months at least). I've excluded NAT port exhaustion, memory exhaustion and my ISP doesn't run CGNAT. The issue presents both on Windows and Linux machines, which means the culprit is most probably the ISP.

The issue at hand is, how do I investigate and document such a problem on my side?

closed as too broad by Ron Maupin Jul 22 at 14:20

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


You state that TCP connections run fine once they get established. That makes a cause on the ISP's network unlikely: ISP routers are usually stateless, so they don't care for layers above the network (IP) layer, and (random) packet loss would impact all packets alike, during and after establishing a connection.

More likely, your NAT router fails to establish new NAT sessions. This may be due to port exhaustion, memory exhaustion or some other system limitation. You should check the router for logged errors and warnings, memory or other resource exhaustion or such.

If router diagnosis doesn't locate the problem you might need to run a packet capture on your NAT router's WAN interface to make sure that TCP SYNs etc. make it across the router. You can also compare that capture to one made on an outside, known-good host. If you're sure that packets make it across your router and don't make it to the ultimate destination, then your ISP needs to answer some questions.

  • While you have a (very, very) fair point, I did not change anything in the network configuration & I have restarted the router multiple times, and the problem presents immediately after a reboot, which means resource (port, memory, etc.) exhaustion is unlikely. I will do a very simple test this evening: I'm going to route traffic through a different ISP from the same router. If that fails to identify the culprit, I'm going to run the other tests you suggested. – rrrrrrrrrrrrrrrr Jul 21 at 18:53
  • @rrrrrrrrrrrrrrrr Nothing in the logs? – Zac67 Jul 21 at 19:36
  • Nope, nothing of interest. – rrrrrrrrrrrrrrrr Jul 21 at 21:21
  • 1
    That first paragraph would only hold if the ISP is not applying CGNAT, right? If this is a new development then that's possibly something that has changed on the ISP end. Of course, if @rrrrrrrrrrrrrrrr is on a business plan that's unlikely - CGNAT is usually residential/consumer only, barring a mixup on the ISP side. – Bob Jul 22 at 2:59
  • @bob Absolutely - however even then, resources for carrier-grade NAT should be ample and never run out. – Zac67 Jul 22 at 6:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.