Management VLAN Migration — OPNsense & Omada¶

This guide covers migrating Omada managed switches and APs from flat LAN management to a dedicated MANAGEMENT VLAN when using OPNsense as the gateway (non-Omada router scenario).

This is Topology 2 in TP-Link's official documentation: How to configure Management VLAN in Omada SDN Controller

Overview¶

By default, Omada devices are managed over whatever network they're on — typically a flat LAN (192.168.0.x). Moving management traffic to a dedicated VLAN isolates it from client traffic, reduces attack surface, and makes the network easier to reason about.

The challenge: the Omada controller itself is likely on a different VLAN (e.g. SERVERS), and after migration the switches will be on a separate MANAGEMENT VLAN. OPNsense must route between them, and firewall rules must explicitly permit it.

Network Reference¶

This guide uses the following addressing. Adjust to match your own setup.

Prerequisites¶

Before touching anything in Omada, the following must be in place in OPNsense. Skipping any of these will cause devices to disconnect and be unrecoverable without physical access.

1. MANAGEMENT VLAN Interface¶

The MANAGEMENT VLAN interface must exist on OPNsense with a static IP and DHCP range.

Interfaces → [MANAGEMENT]: - IPv4: Static, <MGMT_GATEWAY>/24

Services → Dnsmasq → DHCP ranges: - Interface: MANAGEMENT - Range: .100 – .200 in <MGMT_SUBNET>

2. DHCP Option 138 — Omada Controller Discovery¶

After migration, switches reboot into the MANAGEMENT VLAN. They can no longer find the Omada controller by broadcast (broadcast doesn't cross VLANs). DHCP Option 138 (CAPWAP AC) embeds the controller IP in the DHCP response so the switch knows where to connect.

Services → Dnsmasq → DHCP options → Add:

Without this, switches survive a single session but become orphaned after a reboot.

3. Firewall Rule — Allow Omada Controller to Reach MANAGEMENT VLAN¶

The Omada controller runs on the SERVERS VLAN (<OMADA_CONTROLLER_IP>). After migration, the switches are on the MANAGEMENT VLAN (<MGMT_SUBNET>). Without an explicit allow rule, OPNsense blocks this traffic.

Firewall → Rules → SERVERS → Add (place ABOVE any block rules):

Order matters. This rule must be above any "Block SERVERS to MANAGEMENT" rule. OPNsense evaluates rules top to bottom, first match wins.

Example SERVERS rules in correct order:

1. PASS   — <OMADA_CONTROLLER_IP> → MANAGEMENT net    [Allow Omada to manage MGMT VLAN]
2. BLOCK  — SERVERS net → TRUSTED net            [Block SERVERS to TRUSTED]
3. BLOCK  — SERVERS net → MANAGEMENT net         [Block SERVERS to MANAGEMENT]
4. PASS   — SERVERS net → any                    [SERVERS Internet Access]
5. PASS   — SERVERS net → <SERVER_GATEWAY>:53 DNS      [Force DNS to AdGuard - SERVERS]

4. DHCP Option 6 — Push Correct DNS to MANAGEMENT Devices¶

Switches and APs use DNS for NTP lookups and firmware update checks. Push the correct DNS server for the MANAGEMENT VLAN.

Services → Dnsmasq → DHCP options → Add:

5. NAT DNS Redirect for MANAGEMENT¶

Prevents devices on the MANAGEMENT VLAN from bypassing your DNS server.

Firewall → NAT → Destination NAT (Port Forward) → Add:

6. Verify OPNsense is Reachable on MANAGEMENT VLAN¶

From any device on the network, confirm OPNsense responds on the MANAGEMENT VLAN interface before touching any switches:

ping <MGMT_GATEWAY>

If this doesn't respond, do not proceed — the MANAGEMENT VLAN interface is not configured correctly.

Trunk Profile Verification¶

Every trunk port in the chain from OPNsense to each switch must carry the MANAGEMENT VLAN (<MGMT_VLAN_ID>) tagged. Verify in Omada:

Settings → Wired Networks → Switch Profile → [your trunk profile]

Confirm <MGMT_VLAN_ID> - MANAGEMENT is in the Tagged Networks list alongside all other VLANs.

If the MANAGEMENT VLAN is missing from the trunk profile, switches will never receive MANAGEMENT VLAN traffic even if correctly configured.

Migration Order¶

Critical: Always work upstream first. Migrating a downstream switch before its upstream switch is configured means tagged traffic cannot flow, and the device will be unreachable.

OPNsense (already on <MGMT_GATEWAY>)
    ↓
SG2210P (core/upstream switch) → migrate first
    ↓
SG2016P (downstream switch) → migrate second
    ↓
EAP650 (WAP) → migrate last

Switch Migration — SG2210P and SG2016P¶

In Omada: Devices → [Switch] → Config → VLAN Interface → Edit [<MGMT_VLAN_ID> - MANAGEMENT]

Enable the Management VLAN checkbox first — this reveals the gateway and DNS fields.

Click Apply.

The switch will briefly drop from Omada as it transitions. Immediately ping the new IP:

ping <CORE_SWITCH_IP>         # SG2210P
ping <DOWNSTREAM_SWITCH_IP>   # SG2016P

Do not proceed to the next device until the current one has reconnected in Omada and ping responds.

AP Migration — EAP650¶

APs use a different configuration path than switches.

In Omada: Devices → [EAP] → Config → Services → VLAN → Management VLAN

Click Apply.

The EAP will get its IP via DHCP from OPNsense's MANAGEMENT range (.100–.200 in <MGMT_SUBNET>). It does not have a static IP option in this interface — DHCP Option 138 handles controller discovery after each reboot.

Note: The EAP also has an IP Settings section (Config → IP Settings) with a fixed IP reservation field. This is separate and refers to the IP assigned via DHCP reservation, not the management VLAN assignment. Ignore it for this migration — the Services → Management VLAN setting is what matters.

Post-Migration Verification¶

Once all devices are migrated:

# Confirm all devices reachable on MANAGEMENT VLAN
ping <MGMT_GATEWAY>           # OPNsense
ping <CORE_SWITCH_IP>         # SG2210P
ping <DOWNSTREAM_SWITCH_IP>   # SG2016P
ping <AP_IP>                  # EAP650

Confirm in Omada device list that all three devices show IPs in <MGMT_SUBNET> and status Connected.

What Can Go Wrong¶

Switch disconnects and never reconnects¶

Most likely cause: The firewall rule allowing Omada controller (<OMADA_CONTROLLER_IP>) to reach MANAGEMENT VLAN is missing or below a block rule.

Check Firewall → Rules → SERVERS and confirm the allow rule is above the block rule. Then power cycle the switch — it will retry connecting to Omada.

Switch reconnects but Omada can't manage it¶

Most likely cause: DHCP Option 138 is missing or set to the wrong IP. The switch rebooted, got an address in <MGMT_SUBNET>, but doesn't know where the Omada controller is.

Check Services → Dnsmasq → DHCP options → MANAGEMENT and confirm option_capwap_ac_v4 [138] = <OMADA_CONTROLLER_IP>.

Switch completely unreachable after applying config¶

Most likely cause: the MANAGEMENT VLAN (<MGMT_VLAN_ID>) is not in the trunk profile on one or more links in the chain between the switch and OPNsense.

Check the trunk profile in Omada and verify the MANAGEMENT VLAN is tagged. Also verify OPNsense responds at <MGMT_GATEWAY> — if not, the MANAGEMENT VLAN interface itself is the issue.

Factory reset required¶

If a switch becomes completely unrecoverable (no ping, not appearing in Omada):

1. Physically reset the switch (hold reset button 5–10 seconds)
2. The switch returns to flat LAN defaults (192.168.0.x DHCP)
3. All port profiles are wiped — every device connected to it loses its VLAN assignment
4. Connect to Omada via a device on the upstream switch or flat LAN
5. Re-adopt the reset switch
6. Re-apply all port profiles before moving cables back

Lesson learned: When a downstream switch factory resets, any devices with static IPs on VLANs (e.g. servers on <SERVER_SUBNET>) will lose connectivity because their ports revert to Default VLAN 1. Recovery requires either physical access to set a temporary flat LAN IP on the server, or connecting the server temporarily to a working switch upstream.

dnsmasq Host Entries for Infrastructure¶

Once switches are on the MANAGEMENT VLAN with static IPs, add hostname entries so they resolve via .<YOUR_LOCAL_DOMAIN> DNS.

Services → Dnsmasq → Hosts → Add (one per device):

Restart dnsmasq after adding entries.

Security Hardening (Post-Migration)¶

Once management is isolated, add a rule to prevent TRUSTED VLAN devices from accessing MANAGEMENT infrastructure:

Firewall → Rules → TRUSTED → Add (above the TRUSTED full access rule):