NVR is inaccessible from LAN after ISP gateway was replaced.

David Barman
David Barman used Ask the Experts™
on
Network access/routing issue.  The configuration that is place worked perfectly fine until the broadband ISP switch out their cable modem.  See attached diagram for clarification.
The issue at had is before the cable modem gateway was replaced, any workstation on the local LAN (192.168.1.x) was able to access the DVR/NVR camera system using it's address of 10.1.10.101.  However, now that address is pingable from the 192.168.1.x network, but no other network access works (ie. the NVR software can't connect to it).  The NVR system is still accessible from offsite by using the public static ip of the ISP gateway which has port forwarding to the NVR device.  In an ideal world, I would have had the camera system installed behind the network firewall so all devices were on the same ip network.  So I am looking for some input on what might be going on here.  Why would the old ISP gateway allow the communication but the new gateway appears to not.  Is there something that we should communicate to the ISP to change in their gateway to fix this issue?

Any insight is appreciated.
Network-Diagram.pdf
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
David FavorFractional CTO
Distinguished Expert 2018

Commented:
What's required is a manual route between your 192.168.1+ 10.1.10 route, which you'll set at your ISP router.

Your ISP might be engaged to do this work. Likely better if you do this work yourself, so you know how to do this + document the procedure, as this manual route will be required each time your router reboots.

Depending on exact specifics of how your ISP router works you may be able to set a manual route elsewhere in your network.

Note: You show an IP address of 50.241.X.X at your firewall, which doesn't really make sense.

My guess is for all this to work correctly, you'll have to attach your camera network to your firewall, rather than your ISP router.

How exactly you wire all this has many considerations.

As you show your diagram, there's no way to route packets from 50.241.X.X (routable address) to 10.1.10 (private/local/non-routable address), as I suspect all 10.1.10 destined packets will drop at your firewall.

Fixing this might be as simple as connecting your camera system to your firewall appliance, with no manual routes.

Author

Commented:
In my experience, many of the isp broadband gateways will allow but public routable static ips as well as local private addresses (10.x.x.x).  It always worked before until the isp gateway was replaced.

As far as the firewall goes. It's pretty basic. It's a glorified router. I believe it only has one external port.

Author

Commented:
Does it make sense that we would be able to ping the device but no other access works?
Any workstation on the local LAN (192.168.1.x) was able to access the DVR/NVR camera system using it's address of 10.1.10.101.  
Now that address (10.1.10.101) is pingable from the 192.168.1.x network
No other network access works (ie. the NVR software can't connect to it).  
The NVR system is still accessible from offsite by using the public static ip of the ISP gateway which has port forwarding to the NVR device.  

Why would the old ISP gateway allow the communication but the new gateway appears to not.  
Is there something that we should communicate to the ISP to change in their gateway to fix this issue?

I tried here, to parse the problem statement.  I hope it's accurate.  Is it?
You didn't say if this is a residential or commercial ISP service.  That could make a difference in some situations.
Who is the ISP?

Let's look at each path:
Any workstation on the local LAN (192.168.1.x) was able to access the DVR/NVR camera system using it's address of 10.1.10.101.  
This means that packets directed from 192.168.1.0/24 devices would have to traverse the firewall, reach a public address space and somehow be further directed to the 10.1.10.0/24 subnet.  That seems unlikely but possible under rather odd circumstances.

What was the model of the original ISP device?
What is the model of the current ISP device?

I'm very curious how the original ISP device was providing BOTH a public address to the firewall AND a private address to 10.1.10.0/24.  It suggests perhaps a DMZ port.  
For that matter, how is the new ISP device doing it?  
It's not that it's not possible but it is unusual at least.
More information would be helpful here.
I almost can imagine that the camera system was connected to your firewall originally on a separate VLAN and the routing was being done in your firewall.  Is that possible?  May the installers have switched that connection somehow?

Now that address (10.1.10.101) is pingable from the 192.168.1.x networkI find this a little hard to believe as any packets destined for 10.1.10.0/24 will have to be NATted to the public address space first and I see no "reverse NAT" capability to get back to 10.1.10.0.  It can't address 10.1.10.0 in the public internet address space.  This strongly implies a private-address path INSIDE your firewall LAN context.

No other network access works (ie. the NVR software can't connect to it).  
I presume this software is on a computer on your 192.168.1.0 LAN, right?  But, since you can PING it, what happens if you do a trace route?
(Windows command prompt:
tracert 10.1.10.101
What results?  That would be interesting!!

The NVR system is still accessible from offsite by using the public static ip of the ISP gateway which has port forwarding to the NVR device.    So the ISP device is aware of 10.1.10.0 AND is providing 50.247.x.x public address as well.  This suggests that the ISP device is NOT intimately aware of 192.168.1.0/24 - but only within each packet. It suggests that the public IP address for the camera system is NOT 54.247.x.x but rather something more like 54.247.x.y and that there's port forwarding to 10.1.10.0 in the ISP device.
It would be interesting to state the public address for the ISP device in some suitable notation like 54.247.Y.Y as compared to your firewall's public address of 54.247.x.x.  Please?

Hypothesis 1:  
A packet leaves 192.168.1.0/24, destined for 10.1.10.0/24.
The packet MUST BE NATted (or similar) and take off with a 50.247.x.x + a port number assigned to accomodate return packets.
(It cannot send private address destined packets via the public internet).
The destination address would have to be the web public address for the camera system and NOT 10.1.10.101 or similar.
(Maybe the ISP device would handle this but your firewall should not allow it without NAT).
Then the packet might be looped back (mystically)  to 10.1.10.0 and reach the camera system using the suitable port forwarding that's set up and accessible from the internet.  I've not seen this done but it surely isn't far fetched.
Return packets from 10.1.10.0 would be directed to 50.247.x.x and the added port number.
Using that port number, the firewall would return the packet to the originating device AND to an originating port.

Under this hypothesis, PINGs would do this and should work.
So, it suggests that there's a protocol issue using the camera software e.g. http vs. https or .... ?

If this is a residential gateway then I don't generally expect to be able to get much tailoring from the ISP as "one size fits all".  
But, it already looks like you've gone beyond that concern really so maybe it's possible.

I think this is enough for now.  Quite a few questions here.....

Author

Commented:
The is a business class service from Comcast.

Unfortunately, I don't know the model of the devices.  The old router no longer exists.  I have logged into the new one and I don't see any identification as to what make/model it is.

It's not using a DMZ.  The network firewall's WAN interface is connected to one of the LAN ports on the Comcast device.  In addition, the NVR is also connected to a LAN port on the Comcast device.

Yes, the NVR software is on a computer which resides on the 192.168.1.x network.

Hopefully I addressed your questions in your response.

Ideas or suggestions?
Well, the diagram shows that the firewall has a public address.  That's NOT what I'd call the same as connecting to a "LAN port" on the Comcast device unless they are providing a public port as well as a private port.  That is, the nomenclature is a bit unclear.

Are the ports specific ones that Comcast has designated (i.e. for 192.168.1.0 and 10.1.10.0?)  They must be.
I don't know if this applies to you but it seems quite informative.  I've not studied it thoroughly yet....
https://business.comcast.com/help-and-support/internet/comcast-business-ip-gateway-static-firewall/

But, from what I've read, I'd say here are some likely "factoids"
- The router offers a DMZ and that's what your firewall is connected to.
- The router provides 10.1.10.0/24 as a normal LAN-side subnet. That's where you have the cameras.
- The router provides you with a LOT of control over how it's configured - so if all they were to do is replace one for the same model, you might well find that you had a configuration that needs to be set up again in the new machine.  Generally, having a configuration backup is a good idea.

Also, this should be useful:
https://secure.xfinity.com/anon.comcastonline2/support/helpandsupport/businessclass/help_articles/SMC%208014%20Manual.pdf
See page 8 on Static Routing Setup - that likely explains why things work as they do between the two subnets.
And, maybe the Comcast firewall was disabled in the old system - assuming it was similar.  And, maybe the current Comcast firewall is getting in the way of the traffic you're trying to establish.

Author

Commented:
No.  All the ports on the Comcast device are the same.  For either public or private addressing.
So how do you know which is which when you have both public and private addresses?

Is the WAN side of your firewall indeed using a public address?

Author

Commented:
Yes, the firewall is using a public address.
How the gateway handles both private and public addresses, I cannot answer. However, I am 100% positive that is how it is connected and is operating. None of that is my issue however. The configuration I have described is the same as it always has been since the NVR was installed. However, since the Comcast box was replaced, we cannot access the NVR from the internal network behind the firewall.
Yes, I understand the problem and the objective to resolve it.  
How the gateway handles both private and public addresses, I cannot answer. However, I am 100% positive that is how it is connected and is operating. None of that is my issue however.
I'm sorry to suggest that this *is* part of the issue as we need to get to the bottom of things here.
Did you run the traceroute?  That would be helpful.
David FavorFractional CTO
Distinguished Expert 2018

Commented:
You can also use mtr which you can think about as a looping traceroute or ping.

You can run mtr, trying various tests + when you see packet loss go from 100% to 0% you'll quickly see when a test works.

Author

Commented:
Run a traceroute or mtr from where to what?
From Lan pc to 10.1.10.101?
Yes.  From a LAN pc to 10.1.10.101 would be the first thing that I'd try.

Author

Commented:
I can tracert to the dvr from the 192.168.1.x network. WinMTR also works as well.
"can" isn't the issue.  What it shows is what's of interest.
I was able to resolve the issue.

I added a static route to the LAN firewall. The route consisted of a destination of 10.1.10.0, mask of 255.255.255.0, and a gateway of the static ip of the WAN interface on the firewall (50.247.x.x)

Afterwards, the NVR is now working from the local network.

Author

Commented:
Thank you for all of your input.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial