Howto LAN-tunnel guest Wifi

Installing and Using OpenWrt
1

Hi,
I have to Lede devices connected via LAN cable.

1.) ENTRY: DHCP server for LAN and Guest-Wifi and connected to internet
2.) REPL: a DHCP LAN client of ENTRY (using WAN port) and all other ports only supply LAN.

Both devices shall supply a Guest-Wifi network, so that wireless roaming is supported.

The Guest-Wifi on REPL shall use DHCP server for guest network from ENTRY.

relayd (https://wiki.openwrt.org/doc/recipes/relayclient) doesn't seem to be the right solution since all guest traffic between the two devices shall also go through the network cable (LAN).

Do I need to create a tunnel between the two devices where all guest traffic is going through? If so, what is a lightweight and simple to use tunnel implementation available on Lede?

2
  1. Create a new VLAN interface on your WAN port on REPL.
  2. Create another VLAN interface on ENTRY with the same tag (and if needed, plumb the switch ports as well)
  3. Bridge the VLAN interface into the same bridge as the Guest SSID on both boxes.
  4. Bonus points: do the same thing for LAN without getting locked out of REPL, so you are not using a native VLAN.
3

Thanks, got it running.

I thought I need a switch supporting "fid" if I want to reuse the same port for different VLANs.

Second, I was first struggling with the VLAN tagging, since I was reading somewhere that tagging is always required once the same luci config Switch-column (port/cpu) is used twice. But as far as I figured out now, the untagged one is the default, while the tagged ones require explicit setup/definition.
I still have all VLAN CPU rows tagged.

4

Another related performance question:

On ENTRY I in the end know on which LAN port/plug REPL is connect to.
Is there a performance penalty if I configure all ENTRY LAN ports additionally to the Guest-VLAN?

I.e.: will all Guest-VLAN traffic go through the other LAN ports even though there are no other receivers for this Guest-VLAN traffic?

My understanding is that this all happens on ethernet frame level which is somehow or generally broadcasting to every possible destination.

5

Broadcasts. multicasts, and the occasional flooded unicast will go to all ports, but most traffic is
unicast, and once the MAC address has been learned that gets switched only along the spanning
tree from source to destination, unless/until it ages out and has to be learned again with another flooded
unicast.

At least, that's the way it works on most switches... I've never taken the time to verify that behavior
on a SoC switch.