Ttdfjt

Do professors like answering questions from non-students/private citizens?

Rampant sharing of authorship among colleagues in the name of "collaboration". Is not taking part in it a death knell for a future in academia?

Exploiting the delay when a festival ticket is scanned

Can drawing a weapon be part of ANY kind of move action or just moving?

"Valet parking " or "parking valet"

How do you deal with characters with multiple races?

Raindrops in Python

How can I convert a linear narrative into a branching narrative?

Was Donald Trump at ground zero helping out on 9-11?

Is it okay for me to decline a project on ethical grounds?

Are all French verb conjugation tenses and moods practical and efficient?

Boots or trail runners with reference to blisters?

Why does the Rust compiler not optimize code assuming that two mutable references cannot alias?

How does Asimov's second law deal with contradictory orders from different people?

How to choose using Collection<Id> rather than Collection<String>, or the opposite?

Should I put my name first, or last in the team members list

What is the difference between "baruch" and "mevorach" regarding G-d?

Is it possible to tell if a child will turn into a Hag?

How do I make my photos have more impact?

Would it take any sort of amendment to make DC a state?

How to innovate in OR

Does Ubuntu reduce battery life?

Why don't short runways use ramps for takeoff?

PCB design using code instead of clicking a mouse?

TCP connections hang during handshake [closed]

TCP Handshake fails on Cisco ASATCP Handshake Not HappeningTCP retransmissions when we rapidly open multiple connections to the same hostIs application determined before or after TCP handshake?Is MSS negotiated or exchanged during the 3 way handshakeTCP streams/connectionsCalculating 3 way TCP Handshake DurationRandom intercontinental TCP streams are slowHow do TCP connections work?TCP Three Way Handshake?

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;

4

0

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?

tcp nat

share|improve this question

edited Jul 22 at 11:40

rrrrrrrrrrrrrrrr

asked Jul 21 at 7:48

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

14355 bronze badges

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.

add a comment | 

4

0

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?

tcp nat

share|improve this question

edited Jul 22 at 11:40

rrrrrrrrrrrrrrrr

asked Jul 21 at 7:48

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

14355 bronze badges

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.

add a comment | 

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?

tcp nat

share|improve this question

edited Jul 22 at 11:40

rrrrrrrrrrrrrrrr

asked Jul 21 at 7:48

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

14355 bronze badges

share|improve this question

edited Jul 22 at 11:40

rrrrrrrrrrrrrrrr

asked Jul 21 at 7:48

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

14355 bronze badges

share|improve this question

edited Jul 22 at 11:40

rrrrrrrrrrrrrrrr

asked Jul 21 at 7:48

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

14355 bronze badges

asked Jul 21 at 7:48

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

14355 bronze badges

asked Jul 21 at 7:48

rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr

14355 bronze badges

1 Answer
1

active

oldest

votes

8

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.

share|improve this answer

edited Jul 21 at 14:43

answered Jul 21 at 12:21

Zac67Zac67

38.4k22 gold badges2727 silver badges7575 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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
  

  
  
  
  

 | 
show 5 more comments

8

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.

share|improve this answer

edited Jul 21 at 14:43

answered Jul 21 at 12:21

Zac67Zac67

38.4k22 gold badges2727 silver badges7575 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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
  

  
  
  
  

 | 
show 5 more comments

8

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.

share|improve this answer

edited Jul 21 at 14:43

answered Jul 21 at 12:21

Zac67Zac67

38.4k22 gold badges2727 silver badges7575 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  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
  

  
  
  
  

 | 
show 5 more comments

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.

share|improve this answer

edited Jul 21 at 14:43

answered Jul 21 at 12:21

Zac67Zac67

38.4k22 gold badges2727 silver badges7575 bronze badges

share|improve this answer

edited Jul 21 at 14:43

answered Jul 21 at 12:21

Zac67Zac67

38.4k22 gold badges2727 silver badges7575 bronze badges

answered Jul 21 at 12:21

Zac67Zac67

38.4k22 gold badges2727 silver badges7575 bronze badges

answered Jul 21 at 12:21

Zac67Zac67

38.4k22 gold badges2727 silver badges7575 bronze badges