NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Nighthawk M1 MR1100 as modem only, not router
I have a Nighthawk M1 MR1100 Mobile Router and I can say that it works great in IP Passthrough mode with excellent speeds. I do have a need to run it just as a modem and not as a router. I hav...
IP Passthrough hands the wireless carrier's IP directly to your internal router connected to the MR1100's ethernet port.
But in the case of AT&T, they hand out a private IP address (10.x.x.x) which cannot receive incoming connections. This is called Carrier Grade Network Address Translation (CGNAT). Does your MR1100 show a 10.x.x.x IP? If so, the only way to get an inbound connection is to use a VPN that supports ephemeral port forwarding or static IP.
yes, my MR1100 shows 10.x.x.x IP.
I setup a VPN tunnel using two ASA 5505's and all traffic works as it should except devices on MR1100 side are not directly accessible - ie cameras with 192.168.x.x addresses. they can be pinged but no web access.
I don't exactly understand ephemeral ports and looking for workaround for this to work.
Okay, that's a little different than the VPN I was mentioning. I was talking about using a VPN service where you only control your end of the VPN and the other end goes to NordVPN, Windstream, etc and then out to the public internet.
If you are using two VPN firewalls (one on each end) then you control both ends (like one is at work and one is at home... or one in each of two homes).
There are several things that could be blocking HTTP but allowing ping. First make sure VPN Passthrough is allowed in the MR1100. Second, you need to find out if the VPN on the MR1100's side is firewalling port 80 and 443 (HTTP and HTTPS).
I assume since you are opening the cameras by IP address that it is routable. That would mean that it wouldn't matter if they are on the same subnet or not.
When a VPN keeps both sides of the VPN as one subnet (kind of like the VPNs are just network switches), that is called "TAP". This makes it easy for devices to find each other when they only "broadcast" to the local subnet (think of like your phone trying to cast to your chromecast). The downside is that all broadcast traffic will have to go across your VPN, slowing down your cellular link.
When your VPN creates two separate subnets and routes between them (kind of like the VPNs are a router), that is called "TUN". No broadcast traffic crosses the cellular link. Think of it like creating two different broadcast spaces. The only way connections go through the cellular link is if they are directed (routed) traffic. So your phone on one side of the VPN would not see the Chromecast on the other side of the VPN.
If you are curious if you are TAP or TUN, if all your devices are in the same subnet, it is TAP. Like if your network on one side is 192.168.1.x and the other side is also 192.168.1.x, then it is one big mushed together subnet with a very weak link in the middle. But if one side is 192.168.2.x and the other side is 192.168.1.x, then shouted "hey, everybody, listen up!" broadcasts are not heard by the other side. The Youtube app, for example, broadcasts, "Hey, everyone, are there any Chromecast devices on this subnet?"
But in this case, if you are routing (typing an IP address into a browser), then this should work with route and broadcast. So I think it is a firewall rule. It sounds like Side B of your network has been set up to protect it's web clients from the evil, untrustworthy Side A network.
It is worth noting that since your Netgear Cellular device has a 10.x.x.x IP, this means that it cannot receive a "call" from the other side from that VPN device to estabish the VPN connection. This is because 10.x.x.x IPs are not live on the internet (it uses behind the scenes magic at AT&T called "NAT" to allow you to out to the internet, but still wont let the internet connect to you). That means the Netgear Cellular side must always call out to the OTHER side of your VPN, which hopefully has a LIVE public IP (because if both sides have a 10.x.x.x IP, there can be no connection). I assume you've got this to work, since you actually have pings from one site to the other. But this is best understood with the analogy, a private IP (10.x.x.x, 192.168.x.x, and 172.16.x.x through 172.31.255.255) is like having a dialtone that can call out, but has no phone number to receive calls. Having a public IP means having a dialtone to call out AND having a phone number to receive calls. Naturally, if you have two sites, one private (no incoming phone number) and one public (does have incoming phone number), you'd just arrange for the private side to always call the public side. As long as the call can be established, communication over that call can go both ways (both people can talk on a phone call regardless of who dialed who). Private IPs are made to only talk to other private IPs without getting routed on the public internet. This is because all routers on the internet are programmed to destroy packets with a return address of 10.x.x.x, 192.168.x.x, and 172.16.x.x through 172.31.255.255. The exception is if these private IPs can be "encapsulated" (think of those drive thru bank suction tubes where you put your stuff inside a cannister and it sucks it up a tube) and sent through the routable internet. This is what your VPN is. It lets your 192.168.x.x packets hide inside real internet live public IP packets and get transported across the internet and then the cannister is opened and the 192.168.x.x packet is "dumped out" on the other side of the internet. The internet routers never knew they were carrying packets inside of packets.
Anyway, that's enough rambling for now.