…Let’s say you wanted your laptop on SSID2 (LAN2) to access an SMB share on LAN1, there is no way to allow that traffic(protocol) to flow unless you have ‘inter-LAN’ enabled but, you don’t want to open up all protocols to that SMB server from your laptop on SSID2, so, you would then create a Firewall rule blocking LAN2 to LAN1 and place that rule low down in the list. Then, when you create another rule that does allow the TCP/UDP protocol 445 to your SMB’s IP from your laptop’s IP, and place that rule earlier in the processing chain, the packets will flow for that particular protocol path - but everything else will end up hitting the lower rule that blocks everything.

Imagine if you had these two rules in reverse order, your laptop on SSID2 would hit the block-all rule first and never reach the rule that allows it to pass traffic, that’s why you have to manage your rules well, and keep track of what is blocking and what is passing traffic and in what order.

Ah right. If I understand correctly, VLANs are just encapsulated wrappers around LAN traffic and are passed around the network but VLANs just pick-up on the ones that they listen out for ie VLAN 1 sees all packets for every VLAN but is only concerned with anything addressed to VLAN 1 and Inter-LAN just passes the data around it's own LAN number. I suppose VLAN could be considered more software based while inter-LAN perhaps more hardware based???

If my understanding is correct, which is 'better'? That is probably a 'how long is a piece of string' type question but considering they look to be doing the same thing via different methods, I'd assume there are reasons why you'd use one over the other.

Did the firewall rule look right for your suggestion to block the traffic between VLANs?

Ah right. If I understand correctly, VLANs are just encapsulated wrappers around LAN traffic and are passed around the network…

Sort of.
One thing to note here, your Vigor router is a switch and a router combined, keep that in mind.

Here’s a scenario. You have one flat-network, with all nodes on subnet 192.168.10.*/24 (LAN1), then you decide you want another flat-network, completely separate, physically, from the first one.
The second network is using subnet 192.168.20.*/24 (LAN2) and everyone is happy. There is no way a node from LAN1 can communicate with a node on LAN2 or vice-versa, and these two separate networks have broadcast packets flying about because each LAN has a printer on it, let’s say, and that printer keeps broadcasting it’s services to everyone announcing “Hi, I’m here and I’m ready to print or scan for you!”. You then decide one day you want a node on LAN1 to communicate with a node on LAN2, but they are physically not connected, so you purchase a router, which also has a Firewall on it, a ‘Firewall Router’ let’s say, you plug a network cable from LAN1 into the FW Router and a cable from LAN2 into the FW Router as well. You configure the FW Router to route traffic from the LAN1 side to the LAN2 side and vice-versa and you also setup a Firewall rule to block all traffic in both directions. You then configure a new FW rule to allow the two nodes you do want to communicate to pass traffic between each other.
That is the exact same scenario we are creating with your network but, in this example the two networks are made up of two (or more) lots of everything; switches, servers, cabling etc, but they are physically isolated from each other.
Then, some clever dude realised they could merge both of these two physical networks together into one physical network by inventing Virtual LANs (VLANs), effectively isolating the traffic being passed through a switch or switches by internally tagging them with Unique IDs as they enter the switch and steering them to uniquely associated ports within the switch and sending that associated traffic back out of the switch maintaining the separated networks but all through one, physical, network infrastructure. Later, they would improve on this idea by adding the ability to tag certain packets as they leave the switch as well, allowing for multiple networks to be passed down one physical cable to another switch which would then receive those packets, analyse them, and internally pass them onto various associated ports that would eventually lead to individual nodes attached to these ports.
The two distinctions here are VLAN Ports (Access Ports) & VLAN Tagging Ports (Trunk Ports). VLAN ports receive and send plain old packets with no ID (untagged) and VLAN Tagging Ports receive and send packets that have a VLAN ID tag attached to them for identification when they are received by another switch that is configured to deal with them on their specified port or ports.
…

…So here you can see how the LAN part has traditional workings but the VLAN part is used to segregate the LANs as they pass internally (and externally with VLAN Tagging) between and through switches, and yes, the VLAN part is virtual, so software based via a physical setup; but then so is a layer of the LAN system.
The VLAN tagging can also be received by devices intelligent enough to internally pass the VLAN tagged packets to its own LAN or WLAN connection(s) it may be hosting as well.
Take a VOIP desk phone for example, which is located at a workstation with only one LAN wall socket, yet it needs to service two devices, the VOIP phone and the user’s PC. The VOIP phone can receive the VLAN tagged traffic and internally pass the packets to itself and the separated packets out to the PC connected to its additional network port on the back.

Did the firewall rule look right for your suggestion to block the traffic between VLANs?

Yes, perfectly, but you only have LAN1 -> LAN2 selected. So LAN2 will still be able to pass traffic to LAN1. So tick LAN2 in the left box and LAN1 in the right box as well and the same rule will be applied in both directions.
Something to note here, you can’t Firewall a single LAN, so you couldn’t have just LAN1 -> LAN1 selected and expect Firewall-ing between devices on the LAN1 subnet to happen, that won’t work. The FW rules only function between different subnets.

Stupidly I was under the impression that I needed to do a separate firewall rule for each direction (LAN1>LAN2 & LAN2>LAN1) but I can now see what you mean when doing all this in one rule!! obvious when you look at it.

What is a typical way to administer subnetted devices. Say I expanded my current network to include VLAN3, VLAN4 etc... regardless of what devices I have on each subnet, there is likely the need to connect to some devices is order for setup, gather data or diagnose faults etc.
What is a typical way to do this? Would it involve connecting to each of the subnets by joining that network (physical cable or wifi) in order to be on the right subnet for the laptop to be able to communicate with a particular set of devices?
Or would it be a firewall rule to allow one particular laptop access to every VLAN? An example might be if I have two separate IoT VLANS (two different locations maybe) and I wanted to compare the settings of two devices without plugging in backwards and forwards between networks.

Not sure this is particularly good from a security point of view and is not a great example but just to gauge a typical method of administering multiple networks easily (if indeed there is such a thing as easy!!)

Yes, correctly, you are understanding the whole setup much better now.

Create more VLANs and subnets, absolutely, that’s what they are there for, and of course, you would need to add the inter-LAN connections between the administering LAN and all the other LANs, you could simply just add to your current ‘blocking’ rule with the additional LANs so all LANs are blocked between each other, then create a rule, or rules, to allow the administering node - from its LAN - to have access to all the additional LANs.

Be aware of one particular problem you may/will encounter though, which is the lack of broadcast packets crossing subnets.
Certain devices, or rather apps/applications, won’t be able to find other devices without the presence of the broadcast packets. Take for example a FireTV and a FireTV remote control app, these two devices/apps won’t be able to find each other to establish a connection as they use the broadcast packets to do so, and it is quite tricky to resolve this problem, but that’s for another discussion.

But also, yes, you could physically, or via an associated SSID, connect to a particular LAN(subnet) and administer it that way.
Having one node that you control and take caution with, is a necessary evil. If you had a compromised node on one of your LANs which could infect your administering node, well you’d need to be aware of that, but at least your entire network wouldn’t be compromised and that’s the whole point.

It’s a battle these days, between hatted parties, so you have to be cautious, which you are being now, but that’s part of the fun I suppose. Make frequent backups of important nodes and better still, air-gap those backups, you can go deep with the world of security but, it’s better to be aware of the possibilities than burying your head in the sand until it’s too late.

Also, if you have sensible users on your network(s) you have less to worry about, but if you have naive users on your network, it’s far more worrying.