Delete all of this:
Next, we'll edit this:
I'd recommend changing the name of the network to avoid underscores, and maybe make it more obvious (like camera). You also need to change the device to lan4. So I'd recommend making the above look like this:
config interface 'camera'
option proto 'static'
option device 'lan4'
option ipaddr '192.168.4.1/24'
option multipath 'off'
Edit the firewall:
On the zone, we'll adjust the name, network, and remove masquerading and mtu lines. This will now be:
config zone
option name 'camera'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
list network 'canera'
Next, you are not allowing input, so you need to add rules to provide at least DHCP (I'd recommend DNS, too). Add this:
config rule
option name 'Allow-camera-dhcp'
option src 'camera'
option dest_port '67'
option proto 'udp'
option target 'ACCEPT'
config rule
option name 'Allow-camera-dns'
option src 'camera'
option dest_port '53'
option target 'ACCEPT'
Next, we'll adjust the forwarding fules.
The above is only a good option if you trust the Reolink system. With this rule, your reolink nvr will have the ability to connect to your trusted lan... typically this is not desired for camera systems like this which are usually treated as untrusted systems. That said, the name needs to be adjusted to be consistent:
config forwarding
option src 'camera'
option dest 'lan'
You almost certainly want to be able to initiate connections from the lan > camera. That one looks like this:
config forwarding
option src 'lan'
option dest 'camera'
And, as I mentioned, you almost certainly need wan (internet) access if you want to have push notifications. That is obviously contrary to your desire to have this camera system prohibited from accessing the internet. But, for the purposes of testing, that would look like this:
config forwarding
option src 'camera'
option dest 'wan'
So, to recap/explain the forwards:
- camera > lan
- will allow your Reolink to initiate access to your trusted lan.
- This is probably not desirable, especially if you consider the Reolink untrusted
- It's also probably not necessary for push notifications.
- lan > camera
- this will allow your lan to initiate connections to the camera system and is generally the way that most connections would be made.
- This should allow access to the camera systems in many situations, but I do not know if there are any other quirks with the Reolink system.
- You may need to adjust settings/firewalls on the Reolink device itself to ensure that it will accept connections from a subnet that is different than the one that the Reolink uses (i.e. your lan).
- camera > wan
- this gives your Reolink camera system internet access.
- per your stated goals, this is not desired.
- However, it may actually be required for access via their mobile app (I don't know one way or the other)
-This rule is almost certainly required for push notifications.
- You can implement all 3 forwards initially to make sure you can connect as expected and get your push notifications when the camera is on the new network.
- Then, remove the camera > wan forward and see if you can still gain access to the cameras. Also test the push notifications.
- Remove the camera > lan forward and ensure that everything still works.
- test via tailscale
Note that for this to work, you need to specify the IP address of the NVR -- be it an app or a web interface. This means you obviously need to know the IP address of the NVR. But beyond that, an app must have a mechanism by which you can enter the IP address of the NVR (rather than some cloud login) since you'll ultimately have this device offline relative to the internet.
