NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Netgear Nighthawk M5 MR5200 WAN issue
Hi, I have a Netgear Nighthawk M5 MR5200 (ip address 192.168.1.1) that is working with the IP passthrough and it is connected to the WAN port of an Asus AX11000 (ip address 192.168.2.1). I can acces...
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
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
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;
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
@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.
- 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).
- Gotcha! This makes sense! Thanks for that.
Kind regards. 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
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.
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)
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.
And here you are right. And here there is something to be fixed by netgear. Mr5200 with dchp disabled and ip passtrough enable will first release a local IP address, and after 10-60 seconds, will release the external public address.
Currently I can see this thing realtime on my OpenWRT router at home, wan is temporarly assigned 192.168.x.5 and after 10-60 seconds the real external IP is leased and passed, so wan change address accordingly. This will work for 2-3-4 days, than wan loses the address and baaam, mr5200 is connected to lte but not serving connection.
Very buggy.
On pfsense I can't try the mr5200, but try to let this time pass.
the other problem I see is the default 60 second lease time. That's way too fast for stationary use, I tried sending
option dhcp-lease-time 7220;
but the dhcp server apparently doesn't respect the lease time option.
I set
supersede dhcp-renewal-time 7200
That does seem to have slowed down the local dhclient.
rylos wrote:And here you are right. And here there is something to be fixed by netgear. Mr5200 with dchp disabled and ip passtrough enable will first release a local IP address, and after 10-60 seconds, will release the external public address.
Currently I can see this thing realtime on my OpenWRT router at home, wan is temporarly assigned 192.168.x.5 and after 10-60 seconds the real external IP is leased and passed, so wan change address accordingly. This will work for 2-3-4 days, than wan loses the address and baaam, mr5200 is connected to lte but not serving connection.
Very buggy.
You are right, so there are two distinct problems that may or may not be related:
- the first is the rfc1918 ip address assignment: I think what might be happening is that on Reboot the local device dhcp service starts and assigns an rfc1918 ip, then later in the startup process the dhcp server is killed and that allows the remote dhcp server to assign the address.
- the second is that when the unit does disconnect or loses the wan address, apparently it can't recover gracefully and pass thru a new dhcp lease. Very strange behavior indeed.
Kindest Regards
P.S. The next thing NetGear needs to fix is this terrible forum software, the editor is absolutely horrendous!
Appreciate all the answers and insights here folks, truly. Gives me a few things to check into over the Christmas break.
All the very best to all for the holidays!
Cheers,
Hugh
