diff --git a/README.md b/README.md index e9545063c85deb0112cc6b62a60c5b4a3fcc05bd..8ffb1c08d886f613c88b4774c429f7a0ac5ca97f 100644 --- a/README.md +++ b/README.md @@ -69,48 +69,48 @@ interfaces provided by mapcontroller * Mapagent will create interfaces as necessary, adding them to both mapagent and wireless configuration files -**Some notes concerning multiap configuration files.** -While preparing the */etc/config/wireless* configuration, please note that some options may be changed during autoconfiguration proces. +**Some notes concerning multiap configuration files.** +While preparing the */etc/config/wireless* configuration, please note that some options may be changed during autoconfiguration proces. Such options are wps_pushbutton and hidden of wifi-iface section. Actions taken and final value of those options depends mainly on type -of multi_ap interface (value of option multi_ap in current wifi-iface section). +of multi_ap interface (value of option multi_ap in current wifi-iface section). -For backhaul interfaces where -``` +For backhaul interfaces where +``` option multi_ap '1' ``` following rules apply: -* 'hidden' option when provided stays as it is, -* if 'hidden' option is not provided in that wifi-iface section, it is set to hidden=1 by adding +* 'hidden' option when provided stays as it is, +* if 'hidden' option is not provided in that wifi-iface section, it is set to hidden=1 by adding ``` -option hidden '1' +option hidden '1' ``` - -For fronthaul and combined interfaces where + +For fronthaul and combined interfaces where ``` option multi_ap '2' -or +or option multi_ap '3' ``` -following rules apply: +following rules apply: * 'wps_pushbutton' option when provided stays as it is, -* if 'wps_pushbutton' option is not provided in that wifi-iface section, it is set to wps_pushbutton=1 by adding +* if 'wps_pushbutton' option is not provided in that wifi-iface section, it is set to wps_pushbutton=1 by adding ``` option wps_pushbutton '1' ``` - -Additional rule apply when traffic separation is enabled in */etc/config/mapcontroller* by + +Additional rule apply when traffic separation is enabled in */etc/config/mapcontroller* by ``` option enable_ts '1' ``` -in controller section of that config. - +in controller section of that config. + Additional rule concerns guest network which should be added in */etc/config/mapcontroller* file always after already existing networks. -This rule is that guest network will always have wps_pushbutton disabled by +This rule is that guest network will always have wps_pushbutton disabled by ``` option wps_pushbutton '0' ``` always placed in that wifi-iface section. - + ### Example Start Configurations A default configuration file may look as such: diff --git a/docs/QUICK_START.md b/docs/QUICK_START.md index 0eaff8ba9a26d15ade58519ecb361f7ee077a2eb..812027a2c767ee55e779c659b831bdd476328367 100644 --- a/docs/QUICK_START.md +++ b/docs/QUICK_START.md @@ -559,8 +559,6 @@ To enable Guest WiFi and Easymesh Traffic Segregation, the option 'primary_vid' and 'enable_ts' must be set to a non-zero value in the map-controller config's global section. -NOTE: Currently, only primary_vid = '1' is supported: - ``` config controller 'controller' option enabled '1' diff --git a/docs/README-Traffic_Separation.md b/docs/README-Traffic_Separation.md index 97acfcb24568e4ae85e37ebf153e39b4fa27f90d..5d4c5b2789503a136119e78a8a4c88ef9330c052 100644 --- a/docs/README-Traffic_Separation.md +++ b/docs/README-Traffic_Separation.md @@ -20,7 +20,7 @@ comes from the map-controller. To enable traffic separation there are two requirements for map-controller to pass the necessary Traffic Separation and Default 802.1Q Settings TLVs: * Traffic separation must be enabled via configuration (option enable_ts) -* Primary VID must be set to a non-zero value (Today only '1' is supported) +* Primary VID must be set to a non-zero value ``` config controller 'controller' @@ -94,6 +94,33 @@ reconfigure */etc/config/network* to enable VLAN filtering on *al_bridge* (default br-lan) and configure VLAN for Ethernet ports that were already bridged to *al_bridge*. + +### Leveraging 802.1Q Ethernet interfaces + +Due to technical limitations of bridge VLAN filtering, if a packet is ingressing +to the bridge and has to access a layer 3 service running on the bridge, i.e. +DHCP, the packet is untagged and then the outgoing packet is re-tagged with the +set PVID value. Thus true separation cannot be achieved as we can only re-tag +packets with one specific VID. + +To solve this problem 802.1Q Ethernet sub-interfaces, one for each supported +guest VID. The primary vid is still untagged by the bridge and it accesses +services running on the bridge and is re-tagged based on PVID, whereas all the +guest traffic is untagged by the sub-interfaces, which in turn has services +running on them. The sub-interface can then correctly re-tag the egress packet. + +The sub-interfaces require their own DHCP server, firewall rules and network +configuration, which are setup accordingly by map-agent. + +### Default Firewall Rules + +The default firewall rules added will: +* Forward guest zone traffic to wan zone +* Reject INPUT and FORWARD traffic +* Whitelist DHCP, DNS and ping betweens guest client and guest bridge sub-interface + +### Bridge Vlan Usage + Individual VLAN IDs for ports are configured using *bridge-vlan* network config entries. A bridge-vlan section allows a configuration of how a VLAN ID should be appended or untagged at the bridge and each specified port. @@ -153,7 +180,7 @@ an example output can look like: ``` root@iopsys-021000000001:~# bridge vlan -port vlan-id +port vlan-id eth1 1 PVID Egress Untagged 20 50 @@ -169,14 +196,12 @@ eth4 1 PVID Egress Untagged wl0 1 PVID Egress Untagged wl1 1 PVID Egress Untagged br-lan 1 PVID Egress Untagged - 20 Egress Untagged - 50 Egress Untagged + 20 + 50 wl1.1 1 PVID Egress Untagged wl0.1 1 PVID Egress Untagged -wl0.2 1 Egress Untagged - 50 PVID Egress Untagged -wl1.2 1 Egress Untagged - 20 PVID Egress Untagged +wl0.2 50 PVID Egress Untagged +wl1.2 20 PVID Egress Untagged ``` PVID Egress Untagged entries will add/remove VLAN ID tag on for @@ -188,7 +213,8 @@ tags are dropped. In example above *eth2* will: * Remove tags for outgoing frames For wireless port *wl0.2*: -* Transfer untagged traffic to vid 50. +* Tag ingress traffic with vid 50 +* Pass and untag egress traffic with vid 50 ## Wi-Fi Guest-to-Guest Isolation @@ -223,33 +249,84 @@ config agent 'agent' When traffic separation is enabled as provided by **Default 802.1Q Settings TLV** and **Traffic Separation Policy TLV** and the option `guest_isolation` is set -map-agent will create ebtables rules as follows: +map-agent will create ebtables for traffic: +* Traffic that ingress over an ethernet interface and egress via a guest AP + * This rule will *NOT* be applied for an ethernet backhaul interface +* Traffic that ingress over a guest AP interface and egress via an ethernet interface + * This rule will *NOT* be applied for an ethernet backhaul interface +* Traffic that ingress via guest AP and egress via a 4 address mode link +* Traffic that ingress via an 4 address mode link and egress via a guest AP +* Traffic that ingress via a guest AP and egress to another guest AP with the same VID on a different band + +This prevents any traffic from flowing over the guest network between +clients connected at different nodes, radios irrespective of backhaul type. + +Example rules generated: ``` -root@iopsys-44d43771b730:~# ebtables -L +root@smarthub3-001020304001:~# ebtables -L Bridge table: filter + + Bridge chain: INPUT, entries: 0, policy: ACCEPT -Bridge chain: FORWARD, entries: 4, policy: ACCEPT --p 802_1Q -i wl0.2 -o wds+ --vlan-id ! 1 -j DROP --p 802_1Q -i wds+ -o wl0.2 --vlan-id ! 1 -j DROP --p 802_1Q -i wl1.2 -o wds+ --vlan-id ! 1 -j DROP --p 802_1Q -i wds+ -o wl1.2 --vlan-id ! 1 -j DROP + + +Bridge chain: FORWARD, entries: 44, policy: ACCEPT +-i wl0.2 -o wl1.2 -j DROP +-i wl0.2 -o eth1 -j DROP +-i eth1 -o wl0.2 -j DROP +-i wl0.2 -o eth2 -j DROP +-i eth2 -o wl0.2 -j DROP +-i wl0.2 -o eth3 -j DROP +-i eth3 -o wl0.2 -j DROP +-i wl0.2 -o eth4 -j DROP +-i eth4 -o wl0.2 -j DROP +-i wl0.2 -o wds+ -j DROP +-i wds+ -o wl0.2 -j DROP +-i wl1.2 -o wl0.2 -j DROP +-i wl1.2 -o eth1 -j DROP +-i eth1 -o wl1.2 -j DROP +-i wl1.2 -o eth2 -j DROP +-i eth2 -o wl1.2 -j DROP +-i wl1.2 -o eth3 -j DROP +-i eth3 -o wl1.2 -j DROP +-i wl1.2 -o eth4 -j DROP +-i eth4 -o wl1.2 -j DROP +-i wl1.2 -o wds+ -j DROP +-i wds+ -o wl1.2 -j DROP +-i wl0.3 -o wl1.3 -j DROP +-i wl0.3 -o eth1 -j DROP +-i eth1 -o wl0.3 -j DROP +-i wl0.3 -o eth2 -j DROP +-i eth2 -o wl0.3 -j DROP +-i wl0.3 -o eth3 -j DROP +-i eth3 -o wl0.3 -j DROP +-i wl0.3 -o eth4 -j DROP +-i eth4 -o wl0.3 -j DROP +-i wl0.3 -o wds+ -j DROP +-i wds+ -o wl0.3 -j DROP +-i wl1.3 -o wl0.3 -j DROP +-i wl1.3 -o eth1 -j DROP +-i eth1 -o wl1.3 -j DROP +-i wl1.3 -o eth2 -j DROP +-i eth2 -o wl1.3 -j DROP +-i wl1.3 -o eth3 -j DROP +-i eth3 -o wl1.3 -j DROP +-i wl1.3 -o eth4 -j DROP +-i eth4 -o wl1.3 -j DROP +-i wl1.3 -o wds+ -j DROP +-i wds+ -o wl1.3 -j DROP + + Bridge chain: OUTPUT, entries: 0, policy: ACCEPT +root@smarthub3-001020304001:~# ``` -These rules are applied for any fronthaul interface with a guest VLAN ID. The -ebtable rules will drop any traffic with a VLAN ID tag that differs from the -primary that is egressing over a 4address mode link. And vice versa, any traffic -with a VLAN ID tag that differs from the primary ingressing over a 4address mode -link and egressing over a fronthaul interface with a guest VLAN ID will be -dropped. This prevents any traffic from flowing over the guest network between -clients connected at different nodes. - To prevent intra-BSS traffic, hostapd `isolate` option is set over the -guest fronthaul interfaces to prevent client to client traffic. +guest fronthaul interfaces to prevent client to client traffic within a radio. ``` config wifi-iface 'wl1_2_ap' diff --git a/docs/layer3_ts.md b/docs/layer3_ts.md index fb76bbb7e7ec19867c6a40ed43ca365e460129b8..7b09b370c292b0de8c7c04301aa81dfb5ff901a0 100644 --- a/docs/layer3_ts.md +++ b/docs/layer3_ts.md @@ -2,16 +2,20 @@ 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. +setup necessary configuration for when it is enabled. This includes separate +subnets and network zones but not adding interfaces to a guest bridge. -However, using the same solution layer 3 traffic separation is supported but +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. +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.