Skip to content
Snippets Groups Projects
Select Git revision
0 results
Blame Permalink
layer3_ts.md 12.24 KiB

Layer 3 Traffic Separation

The EasyMesh R2 specification only specifies behavior for layer 2 traffic separation, which IOPSYS Multi-AP components support and will automatically setup necessary configuration for when it is enabled. This includes separate subnets and network zones but not adding interfaces to a guest bridge.

Using the existing solution layer 3 traffic separation is supported but must be configured manually. This primarily refers to the creation of bridge-vlan sections, which dictates bridge and Ethernet port tagging rules. If a Traffic Separation TLV is received for which the necessary bridge-vlan sections are already present, map-agent will not setup any additional configuration or modify the existing rules. Map-agent will still be responsible for setting up tagging rules on the wireless interfaces as dictated by the EasyMesh specification and passed map-controller configuration. However, any custom rules that are made must be made with a different naming conventiton used by map-agent.

**** Specificy all naming conventions as example of how not to name *****

This leaves users with flexibility to setup layer 3 traffic separation or any other configuration as they require.

How to Configure

To enable layer 3 traffic separation, it is necessary to manually setup the network, firewall and dhcp configuration as per any custom requirements.

In this how to guide an example it will be shown how to setup a basic use-case where guest clients will receive an IPv4 address from a DHCP server running on a separate bridge, with all traffic egressing and ingressing over said bridge.

Network Configuration

Guest Bridges

First, the bridges must be created. The bridges can have any IP address, netmask etc. In this example we will create two additional guest bridges, one for VID 50 and one for VID 20.

config interface 'guest50'
	option device 'br-guest50'
	option is_lan '1'
	option proto 'static'
	option ipaddr '192.168.50.1'
	option netmask '255.255.255.0'

config device 'br_guest50'
	option name 'br-guest50'
	option type 'bridge'

config interface 'guest20'
	option device 'br-guest20'
	option is_lan '1'
	option proto 'static'
	option ipaddr '192.168.20.1'
	option netmask '255.255.255.0'

config device 'br_guest20'
	option name 'br-guest20'
	option type 'bridge'

Veth Pair

As incoming Wi-Fi client traffic will be ingressing over the wireless interfaces which reside in the al_bridge, we must create a veth pair so this traffic can ingress to the guest bridges.

config device 'guest_dev20'
	option type 'veth'
	option name 'guest_dev20'
	option peer_name 'guest_peer20'

config device 'guest_dev50'
	option type 'veth'
	option name 'guest_dev50'
	option peer_name 'guest_peer50'

These veth pairs must now have their peers attached to the port list of the respective bridge and the source interface to the al_bridge.

config device 'br_lan'
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1'
	list ports 'eth2'
	list ports 'eth3'
	list ports 'eth4'
	list ports 'guest_dev20'
	list ports 'guest_dev50'

config device 'br_guest50'
	option name 'br-guest50'
	option type 'bridge'
	list ports 'guest_peer50'

config device 'br_guest20'
	option name 'br-guest20'
	option type 'bridge'
	list ports 'guest_peer20'

We will now find traffic ingressing over the al_bridge on the guest bridges as well.

VLAN ID Tagging Rules

Finally, we must setup the bridge-vlan sections providing netifd with information on the bridge filtering rules. These rules are in a layer 2 use-case automatically setup by map-agent.

The al_bridge must not untag anything that is not the Primary VLAN ID (unless it is desired that it managed some secondary VLAN IDs), and the guest bridges untag according to the VLAN IDs that they are supposed to manage.

# Ethernet ports and br-lan tag and untaged Primary VLAN ID
config bridge-vlan 'vlan1'
	option name 'vlan1'
	option device 'br-lan'
	option vlan '1'
	option flags 'untagged pvid'
	option local '1'
	list ports 'eth1:*'
	list ports 'eth2:*'
	list ports 'eth3:*'
	list ports 'eth4:*'

# Ethernet ports (as many as desired) and br-lan allow VID 50 to be passed
# guest_dev50 tags and untags VID 50
config bridge-vlan 'vlan50'
	option name 'vlan50'
	option device 'br-lan'
	option vlan '50'
	option flags 'untagged'
	option local '0'
	list ports 'eth1:t'
	list ports 'eth2:t'
	list ports 'eth3:t'
	list ports 'eth4:t'
	list ports 'guest_dev50:*'

# Ethernet ports (as many as desired) and br-lan allow VID 20 to be passed
# guest_dev50 tags and untags VID 20
config bridge-vlan 'vlan20'
	option name 'vlan20'
	option device 'br-lan'
	option vlan '20'
	option flags 'untagged'
	option local '0'
	list ports 'eth1:t'
	list ports 'eth2:t'
	list ports 'eth3:t'
	list ports 'eth4:t'
	list ports 'guest_dev20:*'

Bridge Filtering Configuration

With the network configuration setup and loaded (recommended to be done via /etc/init.d/network restart as reload will not always apply the necessary tagging rules), bridge vlan configuration output should look as follows:

root@iopsys-021000000001:~# bridge vlan
port              vlan-id  
eth1              1 PVID Egress Untagged
                  20
                  50
eth2              1 PVID Egress Untagged
                  20
                  50
eth3              1 PVID Egress Untagged
                  20
                  50
eth4              1 PVID Egress Untagged
                  20
                  50
wl0               1 PVID Egress Untagged
wl1               1 PVID Egress Untagged
br-lan            1 PVID Egress Untagged
guest_peer20      1 PVID Egress Untagged
guest_dev20       20 PVID Egress Untagged
guest_peer50      1 PVID Egress Untagged
guest_dev50       50 PVID Egress Untagged
br-guest20        1 PVID Egress Untagged
br-guest50        1 PVID Egress Untagged
wl1.1             1 PVID Egress Untagged
wl0.1             1 PVID Egress Untagged

An example brctl show output would look as:

root@iopsys-021000000001:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br-guest20		7fff.922f1251b15b	no		guest_peer20
br-guest50		7fff.ec6c9a52b02b	no		guest_peer50
br-lan		7fff.ec6c9a52b027	no		eth1
							eth2
							eth3
							eth4
							guest_dev20
							guest_dev50
							wl0
							wl0.1
							wl1
							wl1.1

Firewall Configuration

In the firewall configuration, each network must be given input, output and forwarding rules by being attached to a firewall zone. In this example we create a zone for each network that accepts all traffic.

config zone 'guest20'
	option name 'guest20'
	list network 'guest20'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone 'guest50'
	option name 'guest50'
	list network 'guest50'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

Next we create the forwarding rules for these zones, forwarding traffic through the wan zone.

config forwarding
	option src 'guest20'
	option dest 'wan'

config forwarding
	option src 'guest50'
	option dest 'wan'

With the configuration setup, we must now reload the firewall rules via i.e. /etc/init.d/firewall reload.

DHCP Configuration

In the DHCP configuration, we create a DHCP server for each network, specifying the desired DHCP ranges.

config dhcp 'guest20'
	option interface 'guest20'
	option start '100'
	option limit '150'
	option leasetime '1h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	option ra_slaac '1'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

config dhcp 'guest50'
	option interface 'guest50'
	option start '100'
	option limit '150'
	option leasetime '1h'
	option dhcpv4 'server'
	option dhcpv6 'server'
	option ra 'server'
	option ra_slaac '1'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'

We can now restart dnsmasq via i.e. /etc/init.d/dnsmasq restart.

Map-Controller Configuration

In map-controller we may now enable Traffic Separation and append two guest networks for VID 20 and VID 50.

config controller 'controller'
	option enabled '1'
	option registrar '5 2'
	option debug '0'
	option primary_vid '1'
	option primary_pcp '0'
	option enable_ts '1'
config ap
	option ssid 'iopsys-vid50'
	option band '5'
	option encryption 'sae-mixed'
	option key '1234567890'
	option vid '50'
	option type 'fronthaul'

config ap
	option ssid 'iopsys-vid20'
	option band '2'
	option encryption 'sae-mixed'
	option key '1234567890'
	option vid '20'
	option type 'fronthaul'

A SIGHUP can then be sent to map-controller as i.e. kill -1 $(pidof mapcontroller).

Verification

Bridge VLAN Filtering

The bridge vlan configuration should now look as such:

root@iopsys-021000000001:~# bridge vlan
port              vlan-id  
eth1              1 PVID Egress Untagged
                  20
                  50
eth2              1 PVID Egress Untagged
                  20
                  50
eth3              1 PVID Egress Untagged
                  20
                  50
eth4              1 PVID Egress Untagged
                  20
                  50
wl0               1 PVID Egress Untagged
wl1               1 PVID Egress Untagged
br-lan            1 PVID Egress Untagged
guest_peer20      1 PVID Egress Untagged
guest_dev20       20 PVID Egress Untagged
guest_peer50      1 PVID Egress Untagged
guest_dev50       50 PVID Egress Untagged
br-guest20        1 PVID Egress Untagged
br-guest50        1 PVID Egress Untagged
wl1.1             1 PVID Egress Untagged
wl0.1             1 PVID Egress Untagged
wl1.2             1 Egress Untagged
                  20 PVID Egress Untagged
wl0.2             1 Egress Untagged
                  50 PVID Egress Untagged

Connecting a Wi-Fi Client

Connecting a client to i.e. wl1.2 we can see that it will receive a DHCP address from the 192.168.20.0/24 subnet:

root@iopsys-021000000001:~# ubus call wifi.ap.wl1.2 assoclist
{
	"assoclist": [
		{
			"wdev": "wl1.2",
			"macaddr": "4a:93:6d:3c:48:21"
		}
	]
}
root@iopsys-021000000001:~# cat /tmp/dhcp.leases
1670580192 4a:93:6d:3c:48:21 192.168.20.139 jakobs-S21 01:4a:93:6d:3c:48:21

Tags on Bridge

By using tcpdump, we can now observe that this clients traffic will now have its VLAN ID 20 tag intact over br-lan, which means it will not egress through from br-lan as no egress rules are set for VID 20 on br-lan.

root@iopsys-021000000001:~# tcpdump -nei br-lan icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
10:08:08.357498 b2:f3:b5:c1:ca:54 > 4a:93:6d:3c:48:21, ethertype 802.1Q (0x8100), length 106: vlan 20, p 0, ethertype IPv4, 192.168.20.1 > 192.168.20.139: ICMP net 20.50.80.209 unreachable, length 68
10:08:10.524492 b2:f3:b5:c1:ca:54 > 4a:93:6d:3c:48:21, ethertype 802.1Q (0x8100), length 106: vlan 20, p 0, ethertype IPv4, 192.168.20.1 > 192.168.20.139: ICMP net 52.114.74.223 unreachable, length 68
10:08:10.993687 4a:93:6d:3c:48:21 > b2:f3:b5:c1:ca:54, ethertype 802.1Q (0x8100), length 102: vlan 20, p 0, ethertype IPv4, 192.168.20.139 > 123.123.123.123: ICMP echo request, id 2136, seq 1, length 64
10:08:10.993886 b2:f3:b5:c1:ca:54 > 4a:93:6d:3c:48:21, ethertype 802.1Q (0x8100), length 102: vlan 20, p 0, ethertype IPv4, 123.123.123.123 > 192.168.20.139: ICMP echo reply, id 2136, seq 1, length 64

However, on br-guest20 we can see the same traffic is untagged and can egress:

root@iopsys-021000000001:~# tcpdump -nei br-guest20 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-guest20, link-type EN10MB (Ethernet), capture size 262144 bytes
10:09:29.127415 b2:f3:b5:c1:ca:54 > 4a:93:6d:3c:48:21, ethertype IPv4 (0x0800), length 590: 192.168.20.1 > 192.168.20.139: ICMP net 31.13.72.53 unreachable, length 556
10:09:29.709500 b2:f3:b5:c1:ca:54 > 4a:93:6d:3c:48:21, ethertype IPv4 (0x0800), length 102: 192.168.20.1 > 192.168.20.139: ICMP net 52.114.74.223 unreachable, length 68
10:09:32.640145 4a:93:6d:3c:48:21 > b2:f3:b5:c1:ca:54, ethertype IPv4 (0x0800), length 98: 192.168.20.139 > 123.123.123.123: ICMP echo request, id 2395, seq 1, length 64
10:09:32.640227 b2:f3:b5:c1:ca:54 > 4a:93:6d:3c:48:21, ethertype IPv4 (0x0800), length 98: 123.123.123.123 > 192.168.20.139: ICMP echo reply, id 2395, seq 1, length 64