Separated subnets with two routers

That is very odd... what IP address does your computer have right now?

192.168.0.7, as usual. The Netgear is listed on the Fritzbox connected devices with its correct 192.168.0.2 address.
I've tried to check with the NAS: I've ssh into it and tried to ping from there with no luck either. If i run "ifconfig" on it, I get that the interface connected to the Netgear has the usual bogus IP 169.254.10.12. But I don't know if it was the same also before

Try connecting to the guest wifi -- what IP address do you get when you do that? And are you able to connect to the internet?

(be sure to unplug/disable ethernet on your computer when you run this test)

I get 192.168.0.19 with gateway 192.168.0.1 when connecting from this PC to the guest WiFi with ethernet disconnected and internet works fine (I'm using it now). I can reach the Fritzbox on 192.168.0.1 and also the NAS on 192.168.0.3 (both things I don't like so much, but whatever!).
I tried to reboot the Fritzbox too, but same story.

That's not the guest wifi subnet -- so you may be connected to the guest wifi SSID, but the subnet is not right.

I'm going to guess that the physical ethernet port is wrong here.

Unplug all the ethernet cables from the Netgear device. Then connect the laptop to one of the physical ports -- see if you get an IP address via DHCP (if/when you do, it will be in the 192.168.1.0/24 network). Try the next port and so on... report on which physical port(s) produce an IP address. In theory, 3 of the ports should do nothing, and one of the ports should provide an IP (it won't be able to reach the internet, but we just need to know what each port is doing).

Nope. No IP address (169.254...) on all 4 ports. :frowning:
Well, I guess I must thank you a lot for your time and effort. Tomorrow I will reset the Netgear and redo the configuration from scratch (now it's too late here) and check when it breaks (I guess the final VLAN part).

That is a surprising result... I wonder what happened.

You can use failsafe mode to view/fix the configs and you don't have to reset to defaults (unless things are really messed up and it's faster to reset). When you do this, you can post your config files and we can review again.

Also, you could try setting up a ping test to 192.168.0.2 from your main network, then connect the Netgear router to the main network, moving one port at a time to see if the pings succeed on any of the ports.

Ok, I've been able to replicate the issue: booted into failsafe mode, reverted the changes to the switches section of /etc/config/network and after reboot the modem was back in reach on 192.168.0.2. So I tried to apply the changes again and it went unreachable again, so the problem is definitely there.

Looking again at the guide you linked me, I've noticed that my devices page of the Netgear doesn't list any existing VLAN (and no eth0.2 device) unlike the picture shown in the guide, can this be the problem?

Ok...
so let's look at the working state and then also actual broken state (we should only need to see the network config file).

so typically VLAN 2 is used as the wan vlan on the switch. In theory, it's arbitrary, but it is always possible there is some underlying file somewhere that has a hardcoded assumption that this will always be the WAN, so we could try vlan 3 instead just in case that is part of the problem.

But let's first see the known working and the known broken (tested and proven to be broken) files

Well, actually I've realized there's someghing broken anyways, provided that, with the "working" configuration I can connect to the Netgear but the clients connected to its wireless get an IP on its subnet (192.168.1.x) that I can check from LuCI but don't get any on the Fritzbox one (192.168.0.x) so aren't visible from the trusted network (so can't use the security cameras) although they can access the internet.
Today I'm a bit busy so I can't fiddle much with it, tomorrow I'll reset the router and reconfigure it from scratch because I'm afraid now it's in some sort of "middle-ground" that makes thing more complicated to understand.
Will let you know...

Ok, I've done it all again from scratch and now everything works as expected: all the devices on the guest WiFi access the internet but not the "trusted LAN" and the Fritzbox can't seem that at all. :+1:

Now all I need is to be able to let the NAS see the security cameras which, atm it can't. I guess there could be two approaches to this: one is using the VLAN like we tried before, but I'm afraid it's a little bit of trial and error process; the other could be, correct me if I'm wrong, just forwarding the ports (or traffic) from the cameras to the NAS in the Netgear firewall, excluding the need to have a physical cable connecting the NAS second NIC to the Netgear OpenWRT.
I had the idea from what I did to connect it to the other cameras I have in my garage (which is too far to join any home WiFi) via a Wireguard tunnel on another OpenWRT cellular modem/router.

I've tried this latter approach myself but I'm stuck because the NAS can't autodiscover the cameras (which is expected and happening also with the garage cameras) and I don't have an IP address to give to it like I do with those through the Wireguard client where I just fill in the client peer address (10.18.7.x). I've tried set it to 192.168.0.2, but they are not recognized.

A third solution that should work ootb without any modification to the configuration, but involves a little money investment, coul be buying a NAS-compatible USB WiFi dongle (something like this, that on local Amazon is even cheaper than that) so the NAS joins the wireless guest and connects to the camera there. Yes, it'd be weird to have two devices that sit on beside the other connected wirelessly, but whatever!

Aside from the question about the logical-to-physical port mapping, there is no real trial-and-error with the VLAN option.

Adjusting the firewall may work, but depending on how the cameras actually work, it's possible that they won't like being routed across two networks (vs switched on a single network).

Again, depending how the NAS works, it actually should only need a connection to the camera network and then you can route to/from the trusted LAN. So only one connection is required.

This seems unnecessary to me, and it's also not a sure thing that it will work as you expect.

Let's take a look at the latest complete config.

Thanks again for your help. Yes, the VLAN solution would be the most elegant so let's try that. Btw why the WiFi dongle could not work? When I connect this computer to the guest WiFi I can access the cameras' webadmin pages on their 192.168.1.x addresses, so the NAS should be able to do the same.
Anyways here are the current configuration files:

/etc/config/network:


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 'fd55:64d4:747f::/48'

config atm-bridge 'atm'
	option vpi '1'
	option vci '32'
	option encaps 'llc'
	option payload 'bridged'
	option nameprefix 'dsl'

config dsl 'dsl'
	option annex 'a'
	option firmware '/lib/firmware/adsl.bin'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0.1'

config device
	option name 'eth0.1'
	option macaddr 'xxx'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.0.2'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option gateway '192.168.0.1'
	list dns '192.168.0.1'

config device
	option name 'dsl0'
	option macaddr 'xxx'

config interface 'wan'
	option device 'dsl0'
	option proto 'pppoe'
	option username 'username'
	option password 'password'
	option ipv6 '1'

config interface 'wan6'
	option device '@wan'
	option proto 'dhcpv6'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 1 2 3 5t'

config device
	option type 'bridge'
	option name 'br-guest'
	option bridge_empty '1'

config interface 'guest'
	option proto 'static'
	option device 'br-guest'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option gateway '192.168.0.1'
	option broadcast '192.168.1.255'

/etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'pci0000:00/0000:00:0e.0'
	option channel 'auto'
	option band '2g'
	option htmode 'HT20'
	option cell_density '0'
	option disabled '1'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'guest'
	option mode 'ap'
	option ssid 'em_wireless'
	option encryption 'psk2'
	option disassoc_low_ack '0'
	option key 'xxx'
	option disabled '1'

/etc/config/firewall


config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	list network 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option masq '1'

config zone
	option name 'wan'
	list network 'wan'
	list network 'wan6'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Guest_DHCP'
	list proto 'udp'
	option src 'guest'
	option dest_port '67-68'
	option target 'ACCEPT'

config rule
	option name 'Guest_DNS'
	option src 'guest'
	option dest_port '53'
	option target 'ACCEPT'

config rule
	option name 'Block_Guest_from_Lan'
	list proto 'all'
	option src 'guest'
	option dest 'lan'
	list dest_ip '192.168.0.0/24'
	option target 'REJECT'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config zone
	option name 'guest'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'guest'

config forwarding
	option src 'guest'
	option dest 'lan'

/etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option localservice '1'
	option ednspacket_max '1232'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option ignore '1'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

config dhcp 'guest'
	option interface 'guest'
	option start '100'
	option limit '150'
	option leasetime '12h'

config host
	option name 'CASA1'
	option dns '1'
	option mac 'xxx'
	option ip '192.168.1.101'

config host
	option name 'CASA2'
	option dns '1'
	option mac 'xxx'
	option ip '192.168.1.102'

Remove the gateway and broadcast lines from below. Broadcast is automatically calculated based on the IP address and subnet mask, so it's unnecessary. Because this is a downstream network, the gateway is only needed if you are using a non-default gateway... in this case, you want the traffic to go through the default (which happens to be the same). Removing the line will ensure that it works even if your upstream subnet or gateway address changes.

Everything else looks good. Make a backup in case anything goes wrong -- easy to restore to this point.

To add the ethernet port, we're going to repeat what we tried to do earlier... take one of the logical ports (3) out of vlan1 and put it in a new VLAN. This time we'll make the new vlan = ID 3.

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 1 2 5t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option vid '3'
	option ports '3 5t'

And then add eth0.3 to the guest bridge:

config device
	option type 'bridge'
	option name 'br-guest'
	option bridge_empty '1'
	list ports 'eth0.3'

Once the changes are complete, reboot the AP and test.

Again, I'm not 100% certain which physical port corresponds to logical port 3. So you may need to try each port by simply plugging a device into each port in succession. But that should do the trick. If you want it on a different physical port, you'd use logical ports 0, 1, or 2 instead.

I made the changes, the devices is bricked again. :cry:
If this can help you figure out, consider that even the wireless is off, the led doesn't turn on at all.

I don't get it... no idea why it would brick. I'm sorry I'm leading you down this path.

You should be able to fix this with failsafe mode and just undo the VLAN3 change.

Maybe try upgrading to 23.05.2 (the latest) and then try again.

1 Like

I don't get it too! What's worse is that even reverting the changes in failsafe mode doesn't unbrick the machine, that needs to be hard-reset to come back to life.
I've now flashed the latest firmware and later I'll repeat the configuration manually, because copying the /etc files from the "last working state" backup, bricks it too. Is there anything that gets changed, in the process shown in the guide you suggested me (I dunno, some dev in /dev), that isn't backed up with the /etc directory backup made by LuCI?
I begin to fear this router, being old and having spent many years, unused, in my garage, has developed some hardware issue. :cry:

That is also particularly strange.

At least now you know what you're aiming for... hopefully won't take too long.

Nothing in /dev, and really only the standard config files in /etc/ (mostly in /etc/config) unless you have otherwise specified changed the backup behaviors.

I mean, maybe?? But this doesn't seem terribly likely to me.

I'm calling in reinforcements...
lets start with @slh -- any ideas here?? you'll see above that we get a subnet working on wifi, then add a new VLAN on the switch (and add that to the bridge) so that one port can be dedicated to the subnet. Once those changes are made, the device bricks. I'm running out of ideas.

1 Like

So, some partial good news: I've reconfigured the router up to the point where it creates the guest WiFi separated from the main LAN before trying to inject ethernet in the mix that seems to cause mayhem. Meanwhile the WiFi adapter I bought (but will return if we find a better solution) to connect the NAS to the guest wireless has arrived from Amazon and, this way, it works, the cameras are seen by the NAS giving it their IP address on the guest LAN.
I know, it's an ugly workaround, and I wouldn't set this thread solved hoping we can find a way to add the ethernet port to the guest LAN (for me and for all those who will find this discussion looking for something similar).