Your subnets are invalid because they overlap. Why are you using /16 networks? Generally, using a /24 is sufficient in terms of a network size, but you could use larger if necessary. However, the /16 you've got defined means that this won't work.
If you want a proper review of your config, please show us the complete config in text form...
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
psherman is spot on, your config could be as simple as the following (I haven't checked the details (read, only /etc/config/network), and I really don't like upper case interfaces (camlan), so I 'needlessly' converted that to lower case <-- would need changing everywhere else as well (firewall/ dhcp):
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd13:28af:8def::/48'
config interface 'lan'
option proto 'static'
option ipaddr '10.10.10.1'
option delegate '0'
list dns '1.1.1.1'
list dns '1.0.0.1'
option device 'eth1.1'
option netmask '255.255.255.0'
config interface 'wan'
option device 'eth0'
option proto 'dhcp'
config interface 'camlan'
option proto 'static'
option device 'eth1.30'
option ipaddr '10.10.30.1'
option netmask '255.255.255.0'
Your r4s (just as RPi4 or x86_64) doesn't have an onboard switch, that makes the router config easier.
So how would I do that in luci? Create a VLAN device under the device menu, and then tie that to the correct interface? This is the output after doing so. I also do not like uppercase, I was just copying a video and thought it was the right way lol. I have changed that as well.
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd13:28af:8def::/48'
config device
option name 'eth1'
config interface 'lan'
option proto 'static'
option ipaddr '10.10.10.1'
option delegate '0'
list dns '1.1.1.1'
list dns '1.0.0.1'
option netmask '255.255.255.0'
option device 'eth1.1'
config device
option name 'eth0'
config interface 'wan'
option device 'eth0'
option proto 'dhcp'
config device
option type '8021q'
option ifname 'eth1'
option vid '1'
option name 'eth1.1'
config device
option type '8021q'
option ifname 'eth1'
option vid '30'
option name 'eth1.30'
option ipv6 '0'
config interface 'camlan'
option proto 'static'
option device 'eth1.30'
option ipaddr '10.10.30.1'
option netmask '255.255.255.0'
I'm still not able to access the camera unless I untag port 4 on VLAN1 and exclude port 4 on VLAN30 on my switch and delete the camlan interface on the NanoPi.
I think I will keep it disabled since all of my IP cameras will have a static IP, unless you can think of a reason to have it enabled anyways?
I don't know why I'm not able to access the camlan from lan via http, I might have to post on Zyxel support forum to see if my switch configuration is wrong.
It's not a requirement as long as your devices have static IPs. However, it could be useful in some situations (or, in some cases, it might be less desirable).
Have you tried using a regular computer (or something like a RPi) on the camlan to see if you can get a connection between the two networks? I'd recommend something that you can test more easily and that would nominally work across subnets. Specifically, some systems do not accept connections from other subnets -- windows by default is like this, so you actually have to adjust the windows firewall to allow inter-VLAN connections. Your camera system may have a similar firewall feature enabled.
Since you're not using DHCP, you'll want to set a computer with a static IP in the correct subnet, and then test the ability for the connection to happen between the LAN and the camlan.
That said, it is also a good idea to verify that all of the information on the cameras/camera system is correct -- it needs to have an IP, subnet mask, and gateway (and nominally DNS, but that is less critical if you are not using the internet on that network). If any of these are missing or incorrect, the camera may not be able to respond.
Your Zyxel switch configuration will not impact routing, but if the device isn't properly configured, your cameras may actually not be properly connected to the expected network.
I'd start with a test with a regular computer (as I described above). In fact, enabling a DHCP server on that subnet and allowing internet connectivity (camlan > wan forwarding) will help you verify if the network is operating properly... if you get an IP via DHCP, you know you've got your switch configured properly. If you can get to the internet, the router is also configured appropriately. Then it is just your cameras that need verification (settings, local firewall rules, etc.).
You can turn off the DHCP server and remove the camlan > wan forwarding after you've verified everything is functioning.
Today I accessed my LAN from my work via wireguard I have running in the LAN network. I wasn't able to ping my camera so I went into my router and re-added the firewall rules I had deleted (lan -> camlan) and was instantly able to ping it. I then tried the camera address and I am able to see it now, and if I remove the firewall rule, I then am not able to reach it. So it seems like it is working now. Weird.
I still haven't had time to test DHCP on the camlan network but I thought I'd update you. The only thing I changed was enabled DHCP on camlan and also set up DNS over DoT.
EDIT: I figured it out! I never changed my desktop back to /24 from /16! As soon as I corrected the mask on my PC I am now able to access the network. It also seems that both the Ports and VLAN Ports tab on my switch both need to match. I don't understand that part yet but I'm glad I was able to get it to work. I then connected my laptop to port 5 and set it to vlan30 untagged, and my laptop pulled 10.10.30.x so DHCP works as well!
In a perfect world that would be the case, but I'm sure plenty of people don't have secure networks for many different reasons so redacting your public information is better than only relying on your network security. It's a good practice to follow.
For a few seconds of work you can easily give yourself another barrier of protection by not making the information public. Kind of like saying its okay to doxx yourself because you know your home security will deter an intruder. If you don't doxx yourself in the first place then you won't have to worry about it.
Your home address is mostly public information but you still shouldn't openly post when its easily avoided. Like a bike lock, yes they are easy to tear through but it adds another layer of security because it takes longer to steal than not having one at all.