KitsNet Network:LAN: KitsNet Wireless Architecture

1 KitsNet Wireless Architecture (Post‑Migration)

CAPsMAN Controller: absolut (CHR) Edge Router / L2 Core: courvoisier LAN DHCP Provider: radix.kitsnet.us (192.168.15.1)

This document describes the intended **steady‑state wireless architecture after the CAPsMAN migration** from Courvoisier to Absolut.

---

1.1 Architecture Overview

The final design separates the **wireless control plane** from the **wireless data plane**.

• CAPsMAN Control Plane – runs on the CHR instance absolut
• Wireless Data Plane – remains on the physical network through the CAP devices
• Client traffic must never transit the CHR

This ensures:

• minimal latency
• no wireless throughput bottleneck on the virtual router
• simplified troubleshooting
• resilience if the CHR is restarted

---

1.2 Controller Role (Absolut)

Absolut runs CAPsMAN only.

Responsibilities:

• CAP discovery
• wireless configuration distribution
• radio channel management
• provisioning of SSIDs
• monitoring and registration table

Absolut **does not forward client traffic**.

Typical verification:

/caps-man manager print
/caps-man remote-cap print
/caps-man registration-table print

---

1.3 CAP Devices

Current CAP devices:

• able
• baker

Hardware: MikroTik cAP ac (RBcAPGi‑5acD2nD)

Each CAP provides:

• 2.4 GHz radio
• 5 GHz radio

Configuration is delivered by CAPsMAN provisioning rules.

---

1.4 SSID Design

Three SSIDs are broadcast.

SSID	Purpose	DHCP Provider	Forwarding Model
KitsNet	Trusted network	radix.kitsnet.us	Local forwarding
KitsNetIN	IoT devices	radix.kitsnet.us	Local forwarding
KitsNetGN	Guest network	courvoisier	Local forwarding to Guest L2

---

1.5 DHCP Architecture

1.5.1 Main and IoT networks

DHCP service is provided by:

radix.kitsnet.us (192.168.15.1)

Clients reach Radix because the CAP locally bridges these SSIDs into the main LAN broadcast domain.

---

1.5.2 Guest network

Guest DHCP remains on courvoisier.

Courvoisier owns:

192.168.12.1/24
bridge: BWF.KitsNetG
DHCP server: DHCP.KitsNetG

Guest traffic must reach this broadcast domain through the wired network.

---

1.6 Data Plane Flow

1.6.1 Trusted WLAN (KitsNet)

Client → CAP radio CAP → LAN bridge LAN → radix DHCP / router

No CAPsMAN traffic path involved.

---

1.6.2 IoT WLAN (KitsNetIN)

Client → CAP radio CAP → LAN bridge LAN → radix DHCP / router

IoT isolation policies may later be enforced via VLANs or firewall rules.

---

1.6.3 Guest WLAN (KitsNetGN)

Client → CAP radio CAP → Guest L2 domain Guest bridge → courvoisier courvoisier → Guest DHCP + firewall policy

Guest network remains isolated from the trusted LAN.

---

1.7 CAPsMAN Provisioning Model

Provisioning ensures that both CAPs operate symmetrically.

Example verification:

/caps-man provisioning print

Expected pattern:

• Able 2.4 GHz → KitsNet + IoT + Guest
• Able 5 GHz → KitsNet + Guest
• Baker 2.4 GHz → KitsNet + IoT + Guest
• Baker 5 GHz → KitsNet + Guest

Channel selection should avoid overlap between the two CAPs.

---

1.8 Security Model

Key protections:

• CAPs locked to the authorized CAPsMAN controller
• Guest traffic isolated from trusted LAN
• IoT devices separated from user devices where possible
• management VLAN access restricted to administrators

To lock CAPs:

/interface wireless cap set lock-to-caps-man=yes

---

1.9 Operational Verification

Useful commands on Absolut:

/caps-man remote-cap print
/caps-man interface print
/caps-man registration-table print

Useful commands on Courvoisier:

/ip dhcp-server lease print
/interface bridge host print

---

1.10 Design Goals

The architecture aims to:

• keep the control plane centralized
• keep the data plane local to the wired network
• prevent wireless client traffic from transiting the CHR
• preserve existing DHCP placement
• maintain simple rollback if needed

---

1.11 Future Improvements

Potential later improvements:

• full VLAN segmentation of SSIDs
• dedicated IoT VLAN
• automated channel planning
• monitoring integration with Zabbix