So what I want to do is connect two switches to the Brume 3's two LAN ports. I don't know if I could get away with an unmanaged switch, or if a managed switch is the only way to do this.
On the Brume 3 LAN 1, there will be a switch with a Google Access Point flashed to OpenWRT. Is it possible to isolate the traffic from the Google Access Point from the other devices connected to the switch? If so, how do I configure this and what kind of hardware is required?
Is it possible to isolate the traffic between the two LAN ports on the Brume 3?I want to ensure there is total and complete isolation, like a brick wall between the two LAN ports for both privacy and security reasons. How do I configure and set this up?
CLI or Luci create the interface, give it the new subnet and details etc.
Configure DNSMasq to serve it. Adguard will by default bind to it.
Create a new IoT firewall zone with whatever forward rules you require for internet access or one controller to see clients on it etc.
I have a separate WiFi router for IoT that plugs into LAN2. I run a RaPi on the same subnet running home assistant so thats the only one that can see other clients as it needs to.
Hardware isolation is physical.
Software isolation can be breached with a bug in code, exploit or whatever. From a home point of view, its fine.
If the Google AP and other devices are connected to the same switch, you will need a managed switch that supports VLANs.
Internet
|
[WAN]
Brume 3
|
[LAN1 / Trunk Port]
|
Managed Switch
|
|-- Port 1: VLAN 10 untagged /PVID 10 --> PC/NAS/Other devices
|
|-- Port 2: VLAN 10 untagged /PVID 10 --> Normal LAN devices
|
|-- Port 3: VLAN 20 untagged /PVID 20 --> Google AP
On the managed switch, configure the port connected to Brume3 as a trunk port. For example, set the main LAN as VLAN10 and the Google AP network as VLAN20. The switch port connected to Brume 3 should allow VLAN10 and VLAN20.
On the managed switch, the port connected to Brume 3 should be configured as VLAN 10 untagged/PVID 10 and VLAN 20 tagged.
The ports for normal LAN devices should be configured as VLAN 10 untagged/PVID 10.
The port connected to the Google AP can be configured as VLAN 20 untagged/PVID 20.
With this setup, normal LAN devices will stay in VLAN 10, while the Google AP and its clients will be placed in VLAN 20.
This plan is simpler if the Google AP can be connected directly to a separate LAN port on Brume 3.
For example, connect the Google AP to LAN2 and connect the normal devices or switch to LAN1.
Internet
|
[WAN]
Brume 3
|
|-- [LAN1] --> Switch / PC / NAS / Other devices
|
|-- [LAN2] --> Google AP
LAN1 can be used for the main LAN with subnet 192.168.8.1/24 or the original LAN subnet.
LAN2 can be used for the Google AP network with subnet 192.168.20.1/24.
Create an internal VLAN for the Google AP port. Go to Network -> Switch.
Configure the switch VLANs like this.
After configuration, clients behind the Google AP should get 192.168.20.x addresses.
Normal LAN devices should stay in the main LAN subnet, such as 192.168.8.x.
This is not an issue with the two LAN ports themselves. The limitation mentioned above is mainly related to using one Brume 3 LAN port as a mixed VLAN trunk.
For your use case, the best option is to use the two physical LAN ports as separate access ports.
For example, LAN1 can be used for the main LAN, and LAN2 can be used for the Google AP network.
Configuration example:
The LAN ports on Brume 3 are connected through an internal switch chip, so they need to be assigned to different internal VLANs before they can work as separate networks.
After this configuration, Brume 3 will see the two networks as separate interfaces.
Then we can assign different IP subnets, DHCP servers, and firewall zones to these two interfaces.
Create a new interface for the Google AP network. Go to Network -> Interfaces -> Add new interface.
With this setup, the Google AP network and the main LAN will be placed in two different subnets.
It isolates the two LAN ports by using separate subnets and firewall zones.
Thanks for the response, but you didn't address whether that is a big or not. Will it be fixed?
Is your solution going to completely isolate LAN1 from LAN2? So even if LAN2 is hacked or its security is somehow compromised, it won't affect traffic on LAN1?
Yes, the behavior mentioned by dsouza is related to the VLAN/PVID issue reported for the Brume 3 switch driver. This has already been forwarded to our R&D team for investigation and code checking.
With the configuration above, LAN1 and LAN2 are placed in different subnets and different firewall zones. As long as no forwarding rule is added between the two zones, LAN2 clients will not be able to access LAN1 clients.
No, there will not be any port forwarding rules on LAN2. The reason why I'm asking is because I'm going to be using an old Google WiFi device that is no longer supported or updated. It does have WPA2, but I know that's no longer recommended anymore. I see this as more of a guest network, and I'll likely even put IoT devices on it.
LAN1 is the secured network where I'll be placing my devices. If for whatever reason LAN2 is compromised, such as a guest PC or IoT device is hacked or infected, are you confident that the devices on LAN1 are safe, secured, and completely isolated from LAN2? Will an attacker that has access to LAN2 be able to see, monitor, or have any possibility to attack LAN1?
With the suggested setup, LAN1 and LAN2 are in different subnets and different firewall zones.
If there is no forwarding rule from LAN2 to LAN1, devices on LAN2 cannot access, scan devices on LAN1 through Brume3.
For a stricter setup, set the LAN2 firewall zone to Input: reject, Output: accept, and Forward: reject, while keeping forwarding from LAN2 to WAN enabled.
This will prevent devices on LAN2 from accessing router management services. In this way, LAN2 can be used as a guest or IoT network.
Sorry for the confusion.
LAN2 -> WAN forwarding is needed if you want LAN2 devices to access the Internet.
Yes, the setup can be done from the LuCI GUI;.
Brume 3 should be able to track routed traffic, such as LAN1/LAN2 to WAN traffic.
