cancel
Showing results for 
Search instead for 
Did you mean: 
Replies are disabled for this topic. Start a new one or visit our Help Center.

Nest Wifi getting lots of ICMP Type 3 (dest unreachable), Code 13 (admin filtered) messages

dresdner353
Community Member

Folks,

    I have an odd scenario with my Nest Wifi setup. It's been around a long time but only recently caused me a lot of grief due to some work-related CDN performance testing we were doing and using home broadband to drive these tests.

I get issues with various wifi and cabled clients where they seem to fail to intermittently connect to a given website. It's not a timeout scenario, more an instant failure. Normally the system works fine and I get excellent mesh performance on the network and very good download results (250mbit). But if the number of connection attempts/rate exceeds what seems to be a low threshold, I get connection failures.

When I did these work-related CDN tests.. 10k downloads of about 500 small files over ten threads (10 downloads at a time), it would literally cause a melt-down and all connection attempts to anything would fail. It would recover a minute later. So this work stuff exaggerated the issue to the point it rendered the broadband unusable. Then it would go away but return instantly if I re-ran the tests.

My Nest setup is two routers cabled to an internal gigabit LAN and a single Point. The primary router is WAN cabled to a Virgin Media cable router (Ireland). The Internet speed is ~250mbits (about 22Mb download/sec). My work Mac is LAN cabled all the way to the Nest router. 

I tried variations on the Nest setup, including setting the mesh up wirelessly (no LAN between both routers) and just using a single router. I also tried wifi only clients, even disconnecting Nest from my home LAN but the issue persists. 

However, and this is the bit that really confuses me..  if I wire my Mac directly or just use the native Wifi on the cable router (bypassing Nest WiFi), this issue goes away. It will not happen and I can do all the downloads I want and CDN tests and nothing fails. The issues only occur when I'm on Nest Wifi or cabled directly to the Nest router via my internal LAN or even directly to the LAN port.

So in isolation terms I can create this issue by cabling the Mac to the LAN port of Nest Wifi and its WAN port cabled to the cable router.  But once I cable directly to the cable router, I don't get the issue. 

I took Wireshark capture on my Mac and these connection "failures" are ICMP messages that appear to come in large volume from my cable broadband router IP. The IPv4 payload is addressed from the cable router IP (192.168.0.1) to my Mac LAN IP 192.168.12.45 (on Nest LAN subnet). An ICMP example portion is shown below saying that I cannot access 13.224.71.15 which is one of the AWS Cloudfront IPs during my CDN testing. 

I've done several factory resets of the routers to try and combat this but the same issue occurs again and again. When the ICMP appears to route from the cable router, you'd be inclined to blame it.. but that does not add up when wifi or direct connection to the cable router never gets this issue. It only occurs with the Nest router in the chain.

So everything points to the Nest router being the culprit. I was wondering if anyone else has seen this kind of behaviour and if its fixable. 

 

 

Example of the ICMP portion of these connection failures:

Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 13 (Communication administratively filtered)
Checksum: 0xba56 [correct]
[Checksum Status: Good]
Unused: 00000000
Internet Protocol Version 4, Src: 192.168.12.45, Dst: 13.224.71.15
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 64
Identification: 0x0000 (0)
Flags: 0x40, Don't fragment
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 62
Protocol: TCP (6)
Header Checksum: 0x1af4 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.12.45
Destination Address: 13.224.71.15
Transmission Control Protocol, Src Port: 61968, Dst Port: 443
Source Port: 61968
Destination Port: 443
Sequence Number: 3165884956

 

Update: A friend suggested I disable the Preferred Activities options in Wifi Settings (so unchecked both videoconferencing and gaming check boxes and the issues seemed to go away). But the problems started to re-occur several hours later. I tried a full factory reset of all routers and points and unfortunately this made no difference after setting up everything again. 

12 REPLIES 12

dresdner353
Community Member

I am going to assume this issue of mine is in fact the other common issue that people have reported of their routers going offline..

https://www.googlenestcommunity.com/t5/Nest-Wifi/Nest-wifi-randomly-going-offline/td-p/8199

Jeff
Community Specialist
Community Specialist

Hi, dresdner353.

Sorry about the issues you're seeing with your network. You might be seeing a similar or even the same problem as in that thread. Are you able to check for me to see which firmware version your WiFi router is using? You can see it in the Home app in the device settings. 

Thanks.

dresdner353
Community Member

Jeff,

   my version is 13729.57.27

I am not seeing any mesh issues or routers going offline. My only problem is that I get these ICMP packets thrown back when trying to connect to sites. It happens continually through the day. Most sites can be refreshed and eventually they work.

I can force the scenario with a simple shell loop:

while true; do curl -s -L google.com; done

..that will happily pull back the google site on loop for about 30 seconds and see a flood of ICMP packets with type 3, code 13. I've traced this with Wireshark. Then pretty much any website access will fail and it then recovers about 30-60 seconds later. 

It feels like some kind of bandwidth limiting in play. I turned off all that chat and gaming prioritisation but the issue persisted. It only occurs via the Nest routers and not via the broadband modem directly. So I cannot blame the provider.

I have factory reset and re-setup the 2 Nest routers and point twice already and the exact same scenario occurs each time. I have also tested with only one router connected and the same issue occurs.

I was suspecting my issue was what others were seeing in that they called it "going offline" but with so many referring to nest routers appearing offline in the Home app, I'm not sure they are the same issue any longer. 

Jeff
Community Specialist
Community Specialist

Thanks for the quick update, dresdner353. That's a lot of helpful info to add to the mix. I'll need to consult with an internal team on this, so this all helps.

For your info, that firmware version you're on is the older version, and the update should be landing on your devices any day now. In the meantime, I'll see what I can find and get back to you.

Thanks.

Jeff
Community Specialist
Community Specialist

Hey, dresdner353.

I haven't received word of a specific fix on this, but I wanted to check back in now that you should have the updated firmware to see if it smoothed out your issue for you. If you're still having problems, let me know.

Thanks.

dresdner353
Community Member

Hi Jeff,

   version now reporting 14150.43.81

The ICMP 3/13 issues is still there unfortunately. I will get refused connections every so often on site clicks or might see a broken image in an opened page. Refreshes will fix this usually a few seconds later.

As mentioned before, a little shell loop will force this.. 

while true; do curl -L google.com; done

.. might run 30 seconds with no issues, showing output from the google page and then... 

curl: (7) Failed to connect to google.com port 80 after 90 ms: Connection refused
curl: (7) Failed to connect to google.com port 80 after 100 ms: Connection refused
curl: (7) Failed to connect to google.com port 80 after 93 ms: Connection refused
curl: (7) Failed to connect to google.com port 80 after 83 ms: Connection refused

..and wireshark capture shows a flood of ICMP 3/13 rejections. I am not seeing any routers or points going offline nor never did I see that. 

I'm suspecting it might be a NAT exhaustion going on here with the NAT layer is running out of source ports for outbound translation. The reason for this is after I create this problem with blunt force above, the entire thing falls apart with all clients wireless and wired seeing the connection failures and then it seems to recover 20-30 seconds later. It has that suggestion that we're filling up some resource and then recovering it shortly afterward.

The one aspect of my network that may be a contributing factor here is that I have 4 Nest cameras in my home and they are streaming video 24x7 to the cloud. But despite that, I can so a speed test and typically record 200-230Mbps. 

Jeff
Community Specialist
Community Specialist

Hey, dresdner353.

I've been looking for answers on this one and I'm just as confused about the odd nature of it as you are. I'm wondering if you have tried going through support yet on this. They should be able to diagnose your setup with you during a phone call or via chat and can dig deeper than I'm able to. You can contact support here: https://bit.ly/3o1aRK5.

If you have any issues getting in touch with support, please let me know.

Thanks.

Jeff
Community Specialist
Community Specialist

Hi, dresdner353.

I'm just following up to see if you were able to reach out and get into contact with support. If you have had any troubles, let me know.

Thanks.

dresdner353
Community Member

not yet but I will get around to this soon. 

Jeff
Community Specialist
Community Specialist

No worries, dresdner353.

If you have any issues, just let me know.

Thanks.

dresdner353
Community Member

Jeff,

   I raised the issue with support. They pulled down diagnostics and came back and said everything looked fine other than the concern that the double-NAT on my broadband router side might be the trigger.

I called the bband proivider (Virgin Media Ireland) and they switched the DOCSIS cable router remotely into IPv4 which then enables Modem mode as an option. After several resets and reboots of the cable router, I got it the point that Nest now says it has the public WAN IP (no longer a LAN IP of the cable router). That stress test I did to force the ICMP 3/13 scenario is now not showing any ICMP issues.

So the problem is resolved. It's very strange that a direct LAN connection to the bband router would not get the same issue that Nest gets but the results do seem to confirm the double-NAT that was the root cause.

Jeff
Community Specialist
Community Specialist

Thanks for the update, dresdner353.

I'm happy to hear it's been sorted out. The double NAT stuff can really cause havoc, for sure. I'll go ahead and mark this as resolved, but if you run into any other issues, please feel free to open up a new discussion.

Thanks!