Netgear Nighthawk M5 MR5200 WAN issue

[rylos]

When is the solution coming? I've the same issue using mr5200 with a Belkin 3200 router; after 2-3 dayes wan is not visible from outside. Rebooting the mr5200 fix the issue.

[salwoo]

If you are working on the update, please also fix the problem with the system clock. I find that it is not accurate all the time. I do the factory reset 2 Months before and I find that the system clock now is 2 hours slower than the actual time. hopefully no your internal program calling the system clock. And at least providing a function to sync with the internet clock.

Fred

---

@JohnPeng wrote:

Thanks for everyone's feedback. Our team is looking into the issue and will make improvements on the connection stabiliy between WAN port and router client.

Regards

---

[Rob_t_g]

Hi Team,

we're running into the same issue with the IP passthough failing every few days. 

ISP is Telstra - Australia. 

I've tested with several Meraki models and Fortigate models. and can supply some debugs if it helps. 

Has the root cause been identified as yet? 

any idea when an updated firmware will be available?

thanks

[rayfol39]

Basically it looks like you need to completely ignore IP Passthrough to acheive stability. What's IP Passthrough meant to acheive??

[PoyntingVector]

Thanks
I am having the same problem, ethernet port unavailable after the night.
Firmware is up-to-date as of today.
This means the device is completely useless for me, unless this will be addressed immediately.
May need to send the device back to Amazon and purchase a better quality alternative.

[rylos]

Actually, in my case it stop working as a wan modem (connected to my router) with IP-Passtrough after 1-3days. When netgear will fix this??? it's unusable!!!

[JohnPeng]

Hi All,

For M5 Ethernet port connection stability issue, I have raised the case to the internal team and hope we can have a solution soon. The root cause of the issue may be related to WWAN side data connection reset by the carrier after certain period of time without data transferring, but the device fails to refresh the IP to the Ethernet client after the connection is resumed.

Thanks for your patience.

[idck_de]

Hi. Great progress that hear from you.

So to work on stabilize and minimize disturb from cellular what you have done is resign plan to data only. Which is worked in your case.

You described another problem that under that MR5200 recoving from ISP connection. The admin page is unaccessible. And here is what i through it could be undone and misunderstood. Furthermore wish more discover will post in here and helps both teams and coummnities to drive it furthers.

It could be resolved by timely. If you closer look it usually takes 10+- mins for MR5200 to reestablish signed address pool to boardcast them to end devices. There's any reason at all to harsh in is the reboot target system by force it to recalibrate all the essential stuffs that matters to end devices connections. Like so your end devices at that time has some sign of warmming that the Network MR5200 provided at the time don't have internet. Therefore it might not interchangeable during MR5200 not in a state of renew or establishing refreshed assignments.

I saw you risen up another issues that releted to MR5200 system timer as well. The MR5200 can be boardcast this functions to end devices by amount of time, And to be sure that MR5200 has granted timely data from servce end. It's linked like chain reactions you see. First is time data giver assigned by Netgear software engineers or co-contractors software builders. Secondly, it's amount of Round trip time cost by transfer it from time giver to MR5200. If you encountering unusual time that wrongly established to end devices you need to work on Sim card provider to ask them a ticket to their server management to check out if any ports that signed to time services is jammed or shuttered. which's most likely in my humbled opinions.

If cellular feedback business as usual. Lets switches to any other similar devices like MR5200 ( I do use Verzion MR2100 from ise as back up). to check out time assignments and how it works out on your end devices.

Other than that, Change your time giver see if works. Most of end devices can have dedicated timing services. If they allow users to change them.

[jeffpritt]

I seem to be encountering the issue identified in this thread as well.

I am on AT&T here in in the US with my MR5200 connected to a Netgear R7000P router.

MR5200 becomes inacessible with no connection to the main router every few days (but only in the morning after a night with presumably no data activity). Nevertheless, the device itself reports on its screen that it is successfully connected to the AT&T cellular network.

The MR5200 replaced a Netgear 2120 modem that had no problems maintaining a solid and stable connection to the R7000P at all times.

Really no other problems with the MR5200 other than its occassional failure to maintain a connection the R7000P.

[rylos]

I've both a MR1100 and the MR5200. 

I can confirm that wan connection (with IP passtrough) to my router is 100% reliable on the MR1100 and connection is lost after 2-3 days on the MR5200 (external IP isn't updated to the lan port). What a joke.

[NoV1m]

Seems like the problem was there in august, it’s December. Do you have any idea of when will it be solved please? Should I purchase another device? Or get mine replaced?

[RonGonz]

I'm going to try this, thanks for the suggestion.

Perhaps a factory reset is necessary after the firmware update to achieve stability, will let  you know the results.

[RonGonz]

after much troubleshooting I believe that this is the correct issue diagnosis.

One thing to note is that my device is attached to pfSense.

The first problem I experienced is that the WebUI configuration dialog defaults the subnet mask to a /32 address space, so by default it is set to 255.255.255.255, rather than a /24 space: i.e. 255.255.255.0.  This causes a configuration issue for IP PassThru on PF Sense because the gateway would appear to be outside the subnet of the interface IP due to the host only mask.  Changing it to /24 subnet mask resolves the issue. 

The other issue is related to TTL.  The default pfSense interface configurations have a TTL of 100 MS to 200MS, and after 200MS the link is considered down.  I believe that without any data being transferred the Cell Tower may downgrade the connection to the device causing increased latency, which could cause the device to be marked down by PFSense.  I increased my latency to 2000MS to prevent the link being marked down.  When data is transferred I believe (but cannot confirm) that likely the LTE tower will increase power to the link and thereby decrease latency again.  Just a couple of hints here, but I could be wrong. 

For now with increased TTL on pfSense the device is not being marked down.  

The problem if the interface gets marked down is of course that this causes the DHCP lease to be released, and then the interface cannot get a new DHCP lease again from the MR 5200 due to the bug you have referenced @JohnPeng 

[RonGonz]

One Final Thought, after running ifTop and monitoring the traffic on this interface, it appears that the NetGear device is sending DNS queries, after doing some research at least one other person has confirmed this.

https://forum.netgate.com/topic/115683/multi-wan-failover-dns-queries-and-open-states-causing-traffi...

---

Looking at this in more depth today. I turned on logging for that floating rule and then filtered the logs with the source IP of the Netgear modem. So what it looks like is happening is the Netgear modem is sending UDP packets to seemingly random IP's on port 53 (DNS) out our main WAN! I have no idea why that would even happen. Anyway I looked at the IP's and used whois to find out where they are going. Most of them are going to IP's owned by Microsoft. Some to Amazon. Others to other large US companies and others to foreign companies. I also disabled the floating rule and did a packet capture on the higher traffic that happens. I can see it still doing DNS queries at large companies.

---

I for one certainly do not appreciate any kind of 3rd party tracking code in the firmware if that's what this is.

[hughhalf]

Hi Ron, All,

I suspect I'm seeing a similar issue with IP Passthrough being unreliable.

Setup is an M5 Nighthawk, Telstra 5G (Mobile Broadband, not Home Internet) and OPNSense firewall (a close relative of pfSense)

With the Nighthawk in "Normal"/NAT mode it's pretty reliable. Switch to IP Passthrough and it's either flakey or just doesn't work at all. For the 5G device to be useable for I need to not have double NAT or, failing that, some other way to determine my external IP addres I guess. Hence the questtion;

You mention in your post @RonGonz;

The first problem I experienced is that the WebUI configuration dialog defaults the subnet mask to a /32 address space, so by default it is set to 255.255.255.255, rather than a /24 space: i.e. 255.255.255.0.  This causes a configuration issue for IP PassThru on PF Sense because the gateway would appear to be outside the subnet of the interface IP due to the host only mask.  Changing it to /24 subnet mask resolves the issue. 

Please pardon my ignorance but I assume here you mean the WebUI for pfSense rather than the M5 - I couldn't find a subnet setting in the latter ?

@JohnPeng realise we're very close to Christmas but are you able to share any insights on a firmware fix on this - my 30 day return window with Telstra is rapidly closing 🙂

Thanks in advance for any insights!

Cheers,
Hugh

[hangiemo]

You'll be behind CGNAT, so your external IP address is pretty useless anyway. That doesn't mean that the passthrough isn't useful of course.

---

@hughhalf wrote:

With the Nighthawk in "Normal"/NAT mode it's pretty reliable. Switch to IP Passthrough and it's either flakey or just doesn't work at all. For the 5G device to be useable for I need to not have double NAT or, failing that, some other way to determine my external IP addres I guess. Hence the questtion;

[RonGonz]

Please pardon my ignorance but I assume here you mean the WebUI for pfSense rather than the M5 - I couldn't find a subnet setting in the latter ?

The Same Dialog That Contains The Ip Pass thru Setting Does Contain A Mask Setting As Well. I Am Speaking Specifically About The Mr5200S Web UI.

Kind Regards

[RonGonz]

@hangiemo wrote: You'll be behind CGNAT, so your external IP address is pretty useless anyway. That doesn't mean that the passthrough isn't useful of course.

That's not true in all cases. When I use ip pass thru I get a live routable internet ip from my carrier. My understanding of cgnat is that it functions the same as nat, in that it tries to translate a private ip to a public one. So I am not sure that I understand what you are talking about.

[hangiemo]

I was referring to Telstra in this case. As to what I was referring to : the IP is useless for inbound traffic. You couldn’t use it to expose services on your IP because it isn’t yours. A topical reason for wanting the IP is for DDNS to potentially expose services. My experience is this is impossible with Telstra 5G (or 4G).

[RonGonz]

Gotcha! This makes sense! Thanks for that.
Kind regards.

[RonGonz]

---

@RonGonz wrote:

The Same Dialog That Contains The Ip Pass thru Setting Does Contain A Mask Setting As Well. I Am Speaking Specifically About The Mr5200S Web UI.

---

[rylos]

The /32 mask on the external IP is correct if you don't want to expose the WAN to other unknow addresses.

The local NET mask is another class and the correct mask for the local net is a complete different thing from the class of a public network.

/32 mask on the LTE link is 99.9999% correct.

Edit: gateway for clients on your local net should be your pfsense private class address (ie 192.168.0.1).

RyLoS

[RonGonz]

---

@rylos wrote:

The /32 mask on the external IP is correct if you don't want to expose the WAN to other unknow addresses.

The local NET mask is another class and the correct mask for the local net is a complete different thing from the class of a public network.

/32 mask on the LTE link is 99.9999% correct.

RyLoS

---

Interesting. I find it troubling generally speaking for the gateway ip to be outside the subnet of the local interface.

How does that make sense?  Case in Point, the workaround to this issue with a /32 subnet mask is listed with a warning that usually indicates a misconfiguration:

Use non-local gateway
Use non-local gateway through interface specific route. This will allow use of a gateway outside of this interface's subnet. 
This is usually indicative of a configuration error, but is required for some scenarios.

Interestingly, this does raise a good point, should DHCP be enabled for this interface?  I.e. does IP Passthrough provide for the PF Sense interface to request the exterior IP rather than assigning the exterior IP to the MR5200 itself?  In this case, I have turned off DHCP for the PF sense interface, and apparently I can still ping via the interface.  So it may be that shutting down DHCP on the interface is the right configuration, rather than attempting to assign the carrier IP to interface, and letting the MR5200 take the IP.  In the latter case, with dhcp disabled for the PFSense interface, it appears that the original conversation regarding the host specific subnet mask becomes irrelevant.  It may just be that I'm mistaken in attempting to "pass-thru" the exterior IP to the PFSense interface.

[rylos]

I think you are making confusion on pfSense. (i use it at work as enterprise firewall, i know it well).

You don't need this check you have screenshotted. It must remain disabled.

On pfSense you have 2 interfaces (in a normale scenario). Local LAN and WAN; pfsense  will make the routing between lan and wan.

Let's assume a simple configuration:

pfSense LAN config.

IP=192.168.0.1

dns=8.8.8.8

IPv4 Upstream gateway=None <- important (yuor lan is not directly connected to internet)

WAN config:

IP config=Dynamic IP (mr5200 in ip passtrhough will serve the dhcp lease always however DHCP server on mr5200 must be disabled!)

Mask= /32

Now your clients in your network should use gateway 192.168.0.1 (ip of lan pfsense)

[RonGonz]

---

@rylos wrote:

I think you are making confusion on pfSense. (i use it at work as enterprise firewall, i know it well).

You're probably right about this, I am a bit confused.

IP config=Dynamic IP (mr5200 in ip passtrhough will serve the dhcp lease always however DHCP server on mr5200 must be disabled!)

---

This might be the issue, regarding whether IP Passthrough forwards the DHCP lease to the pfSense interface or not, in my situation, it appears that DHCP passthrough doesn't work. It appears that the MR5200 takes the external IP lease for itself, and doesn't pass it on. Instead what I see happens is that even though DHCP is disabled on the MR5200, the IP that gets assigned to my interface is an RFC1918 IP, the dhcp lease that gets assigned to pfSense is 172.16.0.1. If I configure dhclient to ignore DHCP lease from 172.16.0.1 and the MR5200 takes the external IP for itself, this is what I see for dhclient output:

 cat igb2_output
dhclient 28545 - - PREINIT
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 1
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 2
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 17
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

If I reboot the device and block dhcp leases from 172.16.0.1, here is what I see when MR5200 initially starts up:

cat igb2_output
dhclient 51487 - - PREINIT
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 2
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 172.16.0.1 rejected.
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 7
DHCPOFFER from 172.16.0.1 rejected.

Eventually, after some time, I see this:

cat igb2_output
dhclient 51487 - - PREINIT
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 2
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 172.16.0.1 rejected.
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 7
DHCPOFFER from 172.16.0.1 rejected.
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 19
DHCPOFFER from 172.16.0.1 rejected.
DHCPDISCOVER on igb2 to 255.255.255.255 port 67 interval 15
DHCPOFFER from 33.X.X.1
DHCPREQUEST on igb2 to 255.255.255.255 port 67
DHCPACK from 33.X.X.1
bound to 33.X.X.141 -- renewal in 60 seconds.