IPC-HDW5231R-ZE not letting me leave gateway blank for dual LAN

May 21, 2018
16
1
Holland, MI
I am trying to follow the wiki footnotes for setting up a blue iris server with dual lan. It says all cameras should be configured with no gateway but my cameras are forcing me to leave at least 1.0.0.1 and when I go to save it says ip address does not match gateway and won't save any changes. What am I doing wrong here??
 
The reason why it didn't work: if you put (for example) 192.168.22.9 in the cam, with a subnet of 255.255.255.0, then a gateway like 10.0.0.1 will never work (not on linux nor windows) as that gateway falls out of the (already wide) subnet. Putting the ip address of the cam itself as gateway doesn't seem smart to me either. Better put the IP address of the LAN adapter of the BI pc, then you're sure that all "outbound" traffic is received on that interface, then you can still define what to do with these packets.

Cheers!
CC
 
The reason why it didn't work: if you put (for example) 192.168.22.9 in the cam, with a subnet of 255.255.255.0, then a gateway like 10.0.0.1 will never work (not on linux nor windows) as that gateway falls out of the (already wide) subnet. Putting the ip address of the cam itself as gateway doesn't seem smart to me either. Better put the IP address of the LAN adapter of the BI pc, then you're sure that all "outbound" traffic is received on that interface, then you can still define what to do with these packets.

Cheers!
CC

That's the intent - to make it not work so as not to give the cam a way out of itself. Killing the gateway is simple and works (to the extent that the cam follows it anyway which isn't absolutely assured) and provides another level of backstop if, for example, someone later makes a change at a higher level which might inadvertently let things slip through. Also limits the device's ability to communicate inside that same subnet. Obviously doesn't work if you need to use outgoing services provided by the cam e.g., email, FTP, etc.
 
That's the intent - to make it not work so as not to give the cam a way out of itself. Killing the gateway is simple and works (to the extent that the cam follows it anyway which isn't absolutely assured) and provides another level of backstop if, for example, someone later makes a change at a higher level which might inadvertently let things slip through. Also limits the device's ability to communicate inside that same subnet. Obviously doesn't work if you need to use outgoing services provided by the cam e.g., email, FTP, etc.

I fully agree, however my "security requirements" are higher than working on "assumptions" that a random chinese cam will behave during its lifetime :) That's why I ditch all "untrusted" stuff into its own playground (vlan).
 
I fully agree, however my "security requirements" are higher than working on "assumptions" that a random chinese cam will behave during its lifetime :) That's why I ditch all "untrusted" stuff into its own playground (vlan).

Don't think that anyone's making any assumptions or suggesting that's all that needs to be done. I'm sure not. All of these things are security nightmares, even the better brand names and US-made products (and most everything else IOT). I put zero trust in any of it. But a lot of people aren't up to and/or don't have the hardware in place to set up VLANs, etc. That at least helps stop typical garden variety stuff like ignoring user settings and beaconing out and otherwise phoning home, setting up P2P connections on their own, etc.