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

Joined
May 21, 2018
Messages
16
Reaction score
1
Location
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??
 

catcamstar

Known around here
Joined
Jan 28, 2018
Messages
1,659
Reaction score
1,193
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
 

Mike A.

Known around here
Joined
May 6, 2017
Messages
3,825
Reaction score
6,377
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.
 

catcamstar

Known around here
Joined
Jan 28, 2018
Messages
1,659
Reaction score
1,193
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).
 

Mike A.

Known around here
Joined
May 6, 2017
Messages
3,825
Reaction score
6,377
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.
 
Top