I have an M6 Pro (MR6550) and a T-Mobile business internet account, and I'm unable to use the M6 in passthrough mode. The M6 (the hotspot) does some pretty inexplicable things. Like ARP my firewall from 192.168.3.1. As I said, my firewall has a public routable (non RFC-1918) address, so 192.168.3.1 is not going to be adjacent on the subnet, and therefore my firewall will drop the ARP request at a minimum, and potentially trigger the IDS as there being misconfiguration of a peer on the network or even someone doing malicious probes. It also sends SSDP packets to my network segment as multicasts. Why? Only hackers use SSDP on a WAN interface: to figure out (1) if you're misconfigured and (2) to know what sort of machines are on your network so they can tailor attacks after fingerprinting the hosts and looking up their attack surfaces and vulnerabilities. But more to the point, it's a modem/bridge. It should be operating at layer 2 on the Ethernet side, and layer 3 on the 4G/5G side. The correct behavior is trivial: (1) When the APN provisioning is received from the 5G carrier, PROXY ARP the default gateway's IP address with your own (M6's) MAC address (or GARP it, that works too if the firewall has been sysctl'd to accept GARP's on a public interface... which is sometimes used for man-in-the-middle attacks on public networks).(2) Then ARP REQUEST the firewall's IP address so you know where to forward the packets. That 2nd step is likely unnecessary, since most IP neighbor implementations cache the address of an ARP requestor in anticipation of their being return traffic (i.e. some sort of answer). You don't need SSDP. Or mDNS. Or to be trying to figure out anything about what's attached to the firewall. That's just suspicious behavior. Also, don't IPv6 SSDP me if I'm not provisioned for IPv6! That just fills my logs with noise. If I do a ping -c 1000 8.8.8.8 then I see spans of 8 or 9 packets being passed, then 20 or so dropped, then 8 or 9 passed, then 20 or so dropped... until the test completes. How did this not turn up during homologation testing? I'm getting 62-70% packet loss!!!

Because for some mysterious reason, .txt attachments aren't allowed:root@OpenWrt2:~# iperf3 -c 84.17.41.11 -p 5201 -t 60 -Z Connecting to host 84.17.41.11, port 5201 [ 5] local 162.191.234.12 port 40326 connected to 84.17.41.11 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 2.12 MBytes 17.8 Mbits/sec 0 729 KBytes [ 5] 1.00-2.00 sec 7.38 MBytes 61.8 Mbits/sec 0 1.17 MBytes [ 5] 2.00-3.00 sec 8.12 MBytes 68.2 Mbits/sec 0 1.54 MBytes [ 5] 3.00-4.00 sec 6.88 MBytes 57.7 Mbits/sec 0 1.91 MBytes [ 5] 4.00-5.00 sec 3.12 MBytes 26.2 Mbits/sec 390 592 KBytes [ 5] 5.00-6.00 sec 1.25 MBytes 10.5 Mbits/sec 671 2.71 KBytes [ 5] 6.00-7.00 sec 1.75 MBytes 14.7 Mbits/sec 92 1.08 MBytes [ 5] 7.00-8.00 sec 8.12 MBytes 68.1 Mbits/sec 0 1.45 MBytes [ 5] 8.00-9.00 sec 6.88 MBytes 57.7 Mbits/sec 0 1.82 MBytes [ 5] 9.00-10.00 sec 2.62 MBytes 22.0 Mbits/sec 1 1.36 KBytes [ 5] 10.00-11.00 sec 0.00 Bytes 0.00 bits/sec 32 24.4 KBytes [ 5] 11.00-12.00 sec 2.75 MBytes 23.1 Mbits/sec 1453 1.39 MBytes [ 5] 12.00-13.00 sec 6.75 MBytes 56.6 Mbits/sec 0 1.76 MBytes [ 5] 13.00-14.00 sec 4.00 MBytes 33.5 Mbits/sec 3 1.75 MBytes [ 5] 14.00-15.00 sec 0.00 Bytes 0.00 bits/sec 6 1.70 MBytes [ 5] 15.00-16.00 sec 0.00 Bytes 0.00 bits/sec 6 1.69 MBytes [ 5] 16.00-17.00 sec 0.00 Bytes 0.00 bits/sec 6 1.69 MBytes [ 5] 17.00-18.00 sec 0.00 Bytes 0.00 bits/sec 7 1.67 MBytes [ 5] 18.00-19.00 sec 0.00 Bytes 0.00 bits/sec 7 1.66 MBytes [ 5] 19.00-20.00 sec 0.00 Bytes 0.00 bits/sec 6 1.65 MBytes [ 5] 20.00-21.00 sec 0.00 Bytes 0.00 bits/sec 6 1.64 MBytes [ 5] 21.00-22.00 sec 2.12 MBytes 17.8 Mbits/sec 7 1.56 MBytes [ 5] 22.00-23.00 sec 2.12 MBytes 17.8 Mbits/sec 7 1.40 MBytes [ 5] 23.00-24.00 sec 0.00 Bytes 0.00 bits/sec 5 1.22 MBytes [ 5] 24.00-25.00 sec 0.00 Bytes 0.00 bits/sec 6 1.18 MBytes [ 5] 25.00-26.00 sec 0.00 Bytes 0.00 bits/sec 4 1.17 MBytes [ 5] 26.00-27.00 sec 0.00 Bytes 0.00 bits/sec 127 86.8 KBytes [ 5] 27.00-28.00 sec 6.12 MBytes 51.4 Mbits/sec 356 1.26 MBytes [ 5] 28.00-29.00 sec 8.38 MBytes 70.3 Mbits/sec 0 1.64 MBytes [ 5] 29.00-30.00 sec 5.62 MBytes 47.2 Mbits/sec 1 1.88 MBytes [ 5] 30.00-31.00 sec 0.00 Bytes 0.00 bits/sec 6 1.60 MBytes [ 5] 31.00-32.00 sec 1.62 MBytes 13.6 Mbits/sec 6 1.58 MBytes [ 5] 32.00-33.00 sec 0.00 Bytes 0.00 bits/sec 7 1.53 MBytes [ 5] 33.00-34.00 sec 0.00 Bytes 0.00 bits/sec 4 1.36 KBytes [ 5] 34.00-35.00 sec 2.50 MBytes 21.0 Mbits/sec 325 1.42 MBytes [ 5] 35.00-36.00 sec 0.00 Bytes 0.00 bits/sec 7 1.19 MBytes [ 5] 36.00-37.00 sec 0.00 Bytes 0.00 bits/sec 6 1.16 MBytes [ 5] 37.00-38.00 sec 0.00 Bytes 0.00 bits/sec 5 2.71 KBytes [ 5] 38.00-39.00 sec 0.00 Bytes 0.00 bits/sec 252 174 KBytes [ 5] 39.00-40.00 sec 3.50 MBytes 29.4 Mbits/sec 199 950 KBytes [ 5] 40.00-41.00 sec 0.00 Bytes 0.00 bits/sec 7 893 KBytes [ 5] 41.00-42.00 sec 0.00 Bytes 0.00 bits/sec 3 884 KBytes [ 5] 42.00-43.00 sec 3.12 MBytes 26.2 Mbits/sec 23 907 KBytes [ 5] 43.00-44.00 sec 7.00 MBytes 58.7 Mbits/sec 0 1.22 MBytes [ 5] 44.00-45.00 sec 7.12 MBytes 59.8 Mbits/sec 0 1.58 MBytes [ 5] 45.00-46.00 sec 6.75 MBytes 56.6 Mbits/sec 0 1.95 MBytes [ 5] 46.00-47.00 sec 0.00 Bytes 0.00 bits/sec 6 1.68 MBytes [ 5] 47.00-48.00 sec 0.00 Bytes 0.00 bits/sec 6 1.67 MBytes [ 5] 48.00-49.00 sec 0.00 Bytes 0.00 bits/sec 6 1.66 MBytes [ 5] 49.00-50.00 sec 0.00 Bytes 0.00 bits/sec 6 1.65 MBytes [ 5] 50.00-51.00 sec 0.00 Bytes 0.00 bits/sec 7 1.64 MBytes [ 5] 51.00-52.00 sec 0.00 Bytes 0.00 bits/sec 6 1.63 MBytes [ 5] 52.00-53.00 sec 0.00 Bytes 0.00 bits/sec 6 1.62 MBytes [ 5] 53.00-54.00 sec 1.62 MBytes 13.6 Mbits/sec 8 1.46 MBytes [ 5] 54.00-55.00 sec 0.00 Bytes 0.00 bits/sec 6 1.43 MBytes [ 5] 55.00-56.00 sec 0.00 Bytes 0.00 bits/sec 16 17.6 KBytes [ 5] 56.00-57.00 sec 2.88 MBytes 24.1 Mbits/sec 10 1.30 MBytes [ 5] 57.00-58.00 sec 0.00 Bytes 0.00 bits/sec 7 1.16 MBytes [ 5] 58.00-59.00 sec 0.00 Bytes 0.00 bits/sec 17 10.8 KBytes [ 5] 59.00-60.00 sec 3.50 MBytes 29.3 Mbits/sec 468 1.09 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 126 MBytes 17.6 Mbits/sec 4624 sender [ 5] 0.00-60.14 sec 123 MBytes 17.1 Mbits/sec receiver iperf Done. root@OpenWrt2:~#Note the intervals were zero packets got through: 15, 19-25, 28-31, ... I've even been told by tech support that my SLA didn't have enough bandwidth and that's why a one packet-per-second test was failing (the ping below).# ping -c 100 24.116.100.90 PING 24.116.100.90 (24.116.100.90): 56 data bytes 64 bytes from 24.116.100.90: seq=0 ttl=54 time=90.591 ms 64 bytes from 24.116.100.90: seq=1 ttl=54 time=52.553 ms 64 bytes from 24.116.100.90: seq=2 ttl=54 time=164.566 ms 64 bytes from 24.116.100.90: seq=3 ttl=54 time=124.372 ms 64 bytes from 24.116.100.90: seq=4 ttl=54 time=60.166 ms 64 bytes from 24.116.100.90: seq=5 ttl=54 time=50.402 ms 64 bytes from 24.116.100.90: seq=6 ttl=54 time=162.617 ms 64 bytes from 24.116.100.90: seq=7 ttl=54 time=57.555 ms 64 bytes from 24.116.100.90: seq=8 ttl=54 time=59.098 ms 64 bytes from 24.116.100.90: seq=25 ttl=54 time=639.718 ms <======= 64 bytes from 24.116.100.90: seq=26 ttl=54 time=60.880 ms 64 bytes from 24.116.100.90: seq=27 ttl=54 time=67.038 ms 64 bytes from 24.116.100.90: seq=28 ttl=54 time=56.424 ms 64 bytes from 24.116.100.90: seq=29 ttl=54 time=63.629 ms 64 bytes from 24.116.100.90: seq=30 ttl=54 time=58.553 ms 64 bytes from 24.116.100.90: seq=31 ttl=54 time=110.747 ms 64 bytes from 24.116.100.90: seq=32 ttl=54 time=56.388 ms 64 bytes from 24.116.100.90: seq=33 ttl=54 time=70.281 ms 64 bytes from 24.116.100.90: seq=52 ttl=54 time=66.309 ms <======= 64 bytes from 24.116.100.90: seq=53 ttl=54 time=181.092 ms 64 bytes from 24.116.100.90: seq=54 ttl=54 time=55.216 ms 64 bytes from 24.116.100.90: seq=55 ttl=54 time=55.123 ms 64 bytes from 24.116.100.90: seq=56 ttl=54 time=53.488 ms 64 bytes from 24.116.100.90: seq=57 ttl=54 time=71.008 ms 64 bytes from 24.116.100.90: seq=58 ttl=54 time=54.779 ms 64 bytes from 24.116.100.90: seq=59 ttl=54 time=64.302 ms 64 bytes from 24.116.100.90: seq=74 ttl=54 time=2816.721 ms <======= 64 bytes from 24.116.100.90: seq=75 ttl=54 time=1816.697 ms 64 bytes from 24.116.100.90: seq=76 ttl=54 time=816.189 ms 64 bytes from 24.116.100.90: seq=77 ttl=54 time=56.368 ms 64 bytes from 24.116.100.90: seq=78 ttl=54 time=58.980 ms 64 bytes from 24.116.100.90: seq=79 ttl=54 time=56.697 ms 64 bytes from 24.116.100.90: seq=80 ttl=54 time=52.612 ms 64 bytes from 24.116.100.90: seq=81 ttl=54 time=66.038 ms 64 bytes from 24.116.100.90: seq=82 ttl=54 time=76.089 ms 64 bytes from 24.116.100.90: seq=83 ttl=54 time=69.489 ms 64 bytes from 24.116.100.90: seq=84 ttl=54 time=205.059 ms <======= --- 24.116.100.90 ping statistics --- 100 packets transmitted, 37 packets received, 63% packet loss round-trip min/avg/max = 50.402/235.076/2816.721 msI've put arrows next to interruptions of packet flows (losses).

I opened a case 7 weeks ago. No progress. Not even a confirmation that they understand the problem or were able to reproduce it on the test bench.

It should be operating at layer 2 on the Ethernet side, and layer 3 on the 4G/5G side.And when I say "operating at [...] layer 3 on the 4G/5G side", I mean stripping the Ethernet encapsulation of 0x800 packets and forwarding them over the radio. Easy peasy.

I cannot seem to find where to set the M6 to bridge mode in the user manual. https://www.downloads.netgear.com/files/GDC/MR6500/MR6500_MR6110_UM_EN.pdf Is this an "Advanced" feature that is not in the user manual?

On the screen, it's "Settings", "More", "IP Passthrough".

M6 and IP-passthrough with routable static IP

22 Replies

hcsprague
Aspirant
Apr 03, 2026
So I have an adjacent issue regarding ip passthru. I just purchased the new Nighthawk 5g M7 - MH7150. My main objective is to use it as a backup WAN connection to my UI UDM-SE when my primary connection is not available. I'll also use it on trips when I'm away from home I had to purchase the docking cradle to get it to work as WAN backup. MY UI Ethernet POE to USB-C adapter did not work. I am only using the cradle to connect to my wan2 port. I have it working with the cradle but the M7 is providing a private 192.168.10.x address to the UDM-SE which I'm assuming is a double-NAT situation and not preferred. I cannot find any setting on the M7 for ip-passthru or bridge mode. I've looked using the mobile app and direct web interface to no avail. I know it is a fairly new device but wondering if anyone has any insight. I opened a ticket with NetGear as well. BTW, I'm using an eSIM from a 3rd-party provider and it is working very nicely as a standard mobile router. I didn't use the NetGear eSIM marketplace. I don't love the mobile app but it is usable.
pprindeville
Aspirant
Feb 26, 2026
Called yesterday because no one has answered my repeated requests for an update.

I was asked, "what sort of adapter is on my PC".

I said 8 weeks ago I was using a Mac Mini.

I was asked, "can you reproduce this on another machine?"

I said 8 weeks ago I reproduced it on a Mac Book Air with an USB-Ethernet dongle as well as using WiFi... and I reproduced it without any computer by generating traffic directly on the routers command line.

I was ask what tests I ran.

I attached output 8 weeks ago of a 1000 packet ping series, as well as running "iperf3".

No wonder they've not made any progress. No one has bothered to read the case notes.
- Plucker
  Guide
  Mar 06, 2026
  I feel for you ... Ive been successfully using my M6 Pro as a backup router on a Unifi UDM Pro for two years with no issues. Unfortunately the M6 decided to update its firmware tonight (with no notification or input on my part) and I can attest that IP Passthrough does NOT work with firmware versionNTGX65_12.01.74.00.
  
  I now have a $600 brick and as its out of warranty thus would require me to purchase a support contract to get any help ... Not really interested in paying them to fix a problem they created.
  
  I think its time to unload it and move on to another solution ....
  - rcpax
    Luminary
    Mar 07, 2026
    if you have IPV6 enabled in your router, disable it. I updated last night (to x.74) and it took me a minute to figure out that when IPv6 is enabled in the router, the M6 fails to give an passthrough IPv4 to it. I don't think this was how the older firmware behaved. I will have to do further testing and compare. I have no pressing need for IPv6 for now, so I might let it be for now.
pprindeville
Aspirant
Feb 23, 2026
And now 6 weeks have passed, and absolutely no progress.

No confirmation that this has been reproduced in the lab, or that a fix is undergoing testing.... or that a drop-dead date has been assigned to getting a fix published...

Shockingly bad technical support.

Not even a pretense of an SLA in time-to-resolution.

But the clincher is that this was a known issue with the M5, so they had foreknowledge of it supposedly before the M6 was even released.
pprindeville
Aspirant
Feb 16, 2026
5 weeks since I provided both all of the debugging information requested, and an engineering solution to the problem (basically just do Proxy ARP like every other modem on the market does) and I still don't have working firmware.

Or even confirmation that they understand the problem or have been able to reproduce it in the lab.
CrimpOn
Guru - Experienced User
Feb 11, 2026
My concern is that the ISP may believe that the device their network is connecting to has a public IP address that they have assigned to that connection and the Firewall believes that it has a different public IP address. If packets keep arriving through the M6 that are addressed to the ISP public IP, the Firewall will ignore them. The goal is to confirm what IP the ISP is sending packets to, and the only way to do that appears to temporarily put the M6 into the default router mode.
- pprindeville
  Aspirant
  Feb 17, 2026
  If someone misconfigures their firewall with the wrong IP address, prefix, and default gateway then this is going to fail no matter what... Doesn't matter if they're on Ethernet, cellular, DOCSIS, or whatever.
CrimpOn
Guru - Experienced User
Feb 06, 2026
Suppose that the Firewall public IP address is 111.222.333.a and the public IP address assigned to the M6 is 333.222.111.b.

If the M6 is put into passthrough mode, then it will send packets to the Firewall addressed to 333.222.111.b and the Firewall will ignore them because it is expecting packets addressed to 111.222.333.a

Put another way, if the M6 is in the default (router) mode, what public IP address does it display?
- pprindeville
  Aspirant
  Feb 08, 2026
  Um... first, they'd need to be on the same subnet.
  
  So do you mean the M6 is on 111.222.333.b?
  
  Again, in passthrough mode the M6 won't have an address. But it will know the address that the firewall behind it has. It will also know the address of the (provider-side) default gateway.
  
  Or are we not talking about IP-passthrough mode any more?
  
  Because:
  
  if the M6 is in the default (router) mode
  
  then that sounds like we're talking about routing mode and not IP passthrough mode.
  - StephenB
    Guru - Experienced User
    Feb 11, 2026
    I don't understand where CrimpOn is going here, but it still might be useful to see if the M6 is better behaved in router mode. Particularly the 60-70% packet loss.
CrimpOn
Guru - Experienced User
Feb 02, 2026
Thanks for explaining where the IP Passthrough option is found.

pprindeville wrote:
my firewall has a public routable (non RFC-1918) address

Is this firewall public IP address the same as the public IP address that the M6 receives from the ISP?
- pprindeville
  Aspirant
  Feb 06, 2026
  Not sure I understand the question: if the hotspot is in IP passthrough mode, then it doesn't have an IP address because it's supposedly operating at layer 2.
CrimpOn
Guru - Experienced User
Feb 01, 2026
I cannot seem to find where to set the M6 to bridge mode in the user manual.

https://www.downloads.netgear.com/files/GDC/MR6500/MR6500_MR6110_UM_EN.pdf

Is this an "Advanced" feature that is not in the user manual?
- pprindeville
  Aspirant
  Feb 02, 2026
  On the screen, it's "Settings", "More", "IP Passthrough".
pprindeville
Aspirant
Feb 01, 2026
It should be operating at layer 2 on the Ethernet side, and layer 3 on the 4G/5G side.
And when I say "operating at [...] layer 3 on the 4G/5G side", I mean stripping the Ethernet encapsulation of 0x800 packets and forwarding them over the radio. Easy peasy.
pprindeville
Aspirant
Feb 01, 2026
I opened a case 7 weeks ago. No progress. Not even a confirmation that they understand the problem or were able to reproduce it on the test bench.

Forum Discussion

M6 and IP-passthrough with routable static IP