Is It Possible To Run IP Cameras From A Different Network Than The Local Network?

I recently spoke with a customer who wanted to see if possible to run the IP cameras from a different network than the local network. Is there a way to do this? The cameras would be connected to NVR and connected to the LAN. New to the IP camera world, I know I shouldn't be but just recently started receiving more and more requests for cameras and I wanted to start using IP.

Thanks


Allan,

No problem to have IPC/NVR in one network and view/playback etc from another network, if that was your question.

I was recently talking with someone in the industry who said he does not you use the customers LAN to run the ip systems and nvr just trying to figure out how he would do that. I have used the customers LAN but I would be nice to find other ways to save on bandwidth on there "main" LAN. Thanks for the response.

Do you use NVRs with dual NICs?

I do not. Is this something I should look into?

With dual NICs you have the ability to set one NIC up on a separate network with only the cameras. Then the other NIC would be on the existing LAN. This would make it so that the NVR would be the only device on the existing LAN. There will be some more responses from more qualified people but I think this would be the solution you're looking for. Read this previous discussion http://ipvm.com/forums/forums/video-surveillance/topics/dual-gigabit-nics-for-recording-servers

You don't really need separate NICs if you're using a PC-based NVR - just build your own network with your own switch, then connect a single uplink to the customer's LAN, and multi-home the NIC like so:

Your cameras would get IPs in the 192.168.2.xxx range; the customer's network is 10.15.1.xxx, with the appropriate gateway for outside connections (if you don't want the machine to have internet access, you can probably leave the gateway out).

This way, the only traffic their network sees is where something else on it communicates with the NVR.

Of course, this does potentially leave the cameras open to access from the rest of the network, though that would require someone else knowing the 192.168.2.xxx range exists. You could also put the camera network on its own VLAN to prevent that access.

If you want to go dual-NIC but the system only has one, a USB adapter is a workable option as well.

This way, the only traffic their network sees is where something else on it communicates with the NVR.

Disagree.

You got no router.

You still have one Ethernet domain. (Make sure not to run DHCP for the 192.168.2.xxx)

At the bare minimum all broadcast traffic is sent to all destinations.

And if you try to setup remote access to a camera you will find it difficult without a default gateway on the 192.168.2.xxx network.

You can't have two gateways on one NIC, for starters (well, you can, but all kinds of odd things can happen).

The cameras in this setup don't require direct remote access - remote into the NVR and hit them from there.

No remote access required, no router required.

What on this setup will be broadcasting?

This setup is working perfectly for me on at least a couple dozen sites, so yes, it does work.

As I say, the other option is to plug your own switch into a managed port on the customer's network, and assign the whole thing its own VLAN - then you can make it routeable and hit everything directly from the outside, if you want. This does have the added benefit of letting you set up NTP sync on the cameras, though we have yet to find a use for that capability.

Matt, the OP is clearly talking about reducing the impact to the corporate lan from the network cameras.

Your suggestion does absolutely nothing to change this impact.

Why? Because without a router, the switches are looking at the same exact traffic with your solution as without, they could care less that the cameras are now on the 192.168.2.xxx network. To them, its just another ARP entry.

Sure it might fool the IT admins for a while, but if for instance the NVR has DHCP enabled, (they often do by default), you will give out 192.168.2.xxx addresses to the 10.x crowd, and bye-bye internet.

Lots of things get broadcast, DHCP, ARP, NetBios, LLDP. This clutter is one of the reasons to keep ethernet domains smaller in size. After some number of hosts, the clutter becomes more than the data.

In addition, whenever a switch doesn't have an ARP table entry for an IP, it broadcasts the data frames to everyone, hoping someone will claim it. With video payloads, this is not insignificant.

I agree this works, I do it myself all the time when working with cameras of different subnets.

But it doesn't reduce traffic and its likely to confuse the IT guys.

Your suggestion does absolutely nothing to change this impact.

The admin on the larger sites where I've done it would disagree - he's never seen an impact on his networks from this setup, and in some cases we're running both cameras and iSCSI to and from the NVR.

but if for instance the NVR has DHCP enabled, (they often do by default), you will give out 192.168.2.xxx addresses to the 10.x crowd

Which NVRs are those? The only ones I've ever seen that do this are the standalone types with built-in PoE switch for the cameras... in which case you're not plugging cameras into the same physical network anyway.

Matt again, your suggestion does NOTHING traffic wise to the network.

Except let you use a 192.168.2.x address on your computer!

Yes/No?

As you can see there are a few ways to interpret your question. The basic answer is yes. While Mr. Ion is correct, I would agree with Undisclosed 1 to install your own switch reduces the impact on all of the customer's current equipment. The customer gets a standalone network dedicated to video. You benefit in that there are no additional loads or demands on the video network. Some cable and a switch and viola. We don't know what his current bandwidth usage and network demands are.

Just a few years ago he would have had to use analog and you would be pulling coax. I see this as no different.

Your question can also be interpreted another way. Can you bring in cameras from a WAN? Are you asking that?

Mark, the OP's second statement helps clarify a bit:

I was recently talking with someone in the industry who said he does not you use the customers LAN to run the ip systems and nvr just trying to figure out how he would do that. I have used the customers LAN but I would be nice to find other ways to save on bandwidth on their "main" LAN.

While Mr. Ion is correct, I would agree with Undisclosed 1 to install your own switch reduces the impact on all of the customer's current equipment.

That's actually what I suggested at the start, adding that your switch can then be connected to the customer's network to provide remote access and internet to the NVR, and using a separate IP range for the cameras to avoid eating up the customer's IP pool.

Yes, you can throw a router in between, or if they have a managed switch, isolate your uplink on a VLAN. My experience, however, is that even without these measures, cameras and an NVR have negligible impact on the network they're uplinked to. The receptionist listening to Spotify at her desk is going to put more load on the customer's network.

A switch has a finite amount of throughput and adding a constant video load is a sure way to saturate that.

I am guessing this is a relatively small install. Some of the small self contained, POE NVR's have the ability to pull IP cameras from the POE network built in, typically on their own network and then also pull IP cameras from the customer side of the network if necessary.

No additional equipment required except for some basic network knowledge to set those cameras as static - out of DHCP range or set as DHCP with non-expiring leases/reservations. A little more knowledge of networks required.

There are many ways to accomplish what you are asking. Choosing which way is best for you would take much more info. I will lay out some of the basics and see if you want to give more input from there.

1) Completely segregated network with it's own switches, router, internet connection, etc.

Under this style of network, the camera LAN would only be accessible by the corporate LAN via an internet connection.

2) Physically segregated network, but sharing a router.

Under this scenario, the camera LAN would still have it's own switches, but would be using an alternate port on a shared router. Under this scenario, you could provide access through the router from the corporate LAN to the camera LAN, if desired. This could be restricted to the bare essential ports and protocols, enhancing security.

3) Physically segregated, but using multiple network cards in your server/NVR

Under this scenario, your recording device, whether it's a VMS server or a dedicated NVR, will need to have multiple network interfaces; one facing the camera LAN and one facing the corporate LAN.

(Matt Ion's way of using one NIC isn't the same as this scenario. Under his one NIC scenario, nothing is segregated, physically or logically.)

4) Virtually segregating the networks via VLANs.

Under this scenario, you would have the camera and corporate LANs on the same switches and router, but configured as virtual LANs (VLANs), which means each LAN would be segregated by use of switch and router configuration.

---------------------------------------

Now, deciding which is best for you is the hard part. If your client has managed switches, a robust router, and an adept IT dept, then option 3 is the most practical. But, if they don't have any of these requirements, option 1 will be your only choice, unless you add a better router ahead of the existing router.

There are no absolute rights an wrongs here. Every option has it's time and place. There are cost and security trade-offs with each option. Knowing your customer well is the first step to choosing the correct option.

I would highly recommend taking the next IPVM networking class.

In a way you could have two gateways on a NIC. You could setup a static, persistent route. Not the best option but it does work.

Still just one default gateway though on a single-homed machine, correct?

With a static route pointing to a new router, which straddles both subnets, if I'm understanding correctly.

Not necessary unless you need to reach another network from both, though.

In the scenario I used above, with two IPs of 192.168.2.xxx/24 and 10.15.1.xxx/24, and a gateway of 10.15.1.254, any connections for a device with a 192.168.2.xxx address will communicate directly with that device; anything looking for 10.15.1.xxx will go directly; and anything else will go to the default gateway, where it gets routed to wherever else it's going.

If you're only ever communicating within your own subnet, you don't even need a gateway entry.

You are correct on the default gateway. Having more than one of those would be a disaster.

Windows does let you do it. The way I understood it is that they are backup default routers, only to be used when the current live one cannot be reached.

I've never had to do that so I don't know. What have you seen happen?

Now, when you have two NIC's on the SAME subnet with two different default gateways, (just one per each), I know that can cause problems in certain cases.