DHCP Issues on VLAN 90 with OPNsense, TP-Link Switch and EAP773 Access Points

[350flyer]

Hello everyone,
I am an amateur home lab and networking enthusiast and am largely self-taught. Networking is not my professional field (Airline Capt), so I am still learning and building my knowledge as I go. Most of what I have learned so far has come from YouTube tutorials, online documentation and forums, hands-on experimentation in my own home lab, and assistance from ChatGPT. I may therefore sometimes use incorrect terminology or overlook something that may seem obvious to more experienced network professionals. I am very willing to learn and would genuinely appreciate any guidance, corrections, or suggestions on the best way to troubleshoot and understand the issuei am facing.


Summary of the problem

I recently created a new Wi-Fi VLAN specifically for access to my CCTV infrastructure. The new network is:

VLAN 90 – CCTV Wi-Fi

The SSID broadcasts correctly from my TP-Link Omada EAP773 access points,  my iPhone can see SSID CCTV WIFI signal but has issues connecting to it (details explained below).

the client does not receive an IP address from DHCP. Instead, after failing to obtain a lease, the client receives a self-assigned address in the:

169.254.x.x range.

The important point is that I have several other VLANs and Wi-Fi SSIDs using exactly the same OPNsense router, TP-Link switch infrastructure, trunk uplink, and EAP773 access points. Those VLANs are all working correctly and clients receive DHCP addresses normally.

At the moment, VLAN 90 is the only VLAN  or any vlan trying to access the other netowrk (CCTV Network) on physical separate port on my i225 NIC.

My objective is to determine systematically where the DHCP traffic for VLAN 90 is failing rather than making random changes to working configurations.

My network architecture

My network is built around an OPNsense router, with VLAN routing and DHCP provided centrally by OPNsense.

OPNsense router

The router hardware is:

Lenovo ThinkCentre M920Q Tiny
Intel Core i7-9700T
32 GB RAM
1 TB SSD
Intel i226 quad-port Ethernet adapter

The current software versions are:

OPNsense 26.7.3_8-amd64
FreeBSD 15.1-RELEASE-p3
OpenSSL 3.5.8

OPNsense handles routing between my various internal networks and VLANs.

General network layout - My architecture is broadly as follows:

                    Internet
                       |
                       |
                    OPNsense
                       |
                       |
                 Main LAN trunk
                       |
                       |
          TP-Link Omada SG3428XPP-M2
                       |
             -------------------
             |                 |
           Port 2            Port 3
             |                 |
           EAP773            EAP773
             |                 |
        Multiple SSIDs   Multiple SSIDs
        Multiple VLANs   Multiple VLANs



The main trunk connection between the TP-Link switch and OPNsense is on: Switch Port 24

The two currently active EAP773 access points are connected to: Switch Port 2 and Switch Port 3

I have four EAP773 access points in total, although only two are currently connected. The other two are available for testing if necessary.

Existing VLANs

I have multiple networks for different purposes, including:

Default/Main Network
Home Lab
Aviation Wi-Fi
Guest Wi-Fi
IoT
Management
CCTV Wi-Fi

The existing VLANs and their associated wireless networks are working correctly. Clients connecting to those existing SSIDs successfully receive:

IP address
Default gateway
DNS information
DHCP lease

This is why the VLAN 90 issue is confusing: the same general infrastructure is already successfully transporting multiple VLANs.

Purpose of VLAN 90 – CCTV Wi-Fi

I created VLAN 90 specifically as a dedicated wireless network for trusted devices that need access to my CCTV infrastructure (CCTV Network) Located on a different physical port (igc3) on my Opnsense router.

The intended clients include:

CCTV monitoring tablets
Trusted computers
Trusted mobile devices

The VLAN has its own:

OPNsense VLAN interface
Dedicated DHCP subnet
Dedicated Kea DHCP pool
Firewall rules

For security reasons, I will not include my exact internal addressing in this post, but the CCTV Wi-Fi VLAN (192.168.90.X/24) uses a separate private subnet from the physical CCTV network (10.10.10.X/24 on igc3)

DHCP

I am using:

Kea DHCPv4

on OPNsense.

For VLAN 90, I have configured:

VLAN interface enabled
VLAN assigned to the correct parent interface
Dedicated DHCP subnet
Dedicated DHCP address pool
OPNsense interface as the gateway
VLAN 90 interface selected/configured in Kea DHCP

Kea DHCP is functioning correctly for my other networks. The issue appears to be isolated specifically to clients connecting through the new VLAN 90 SSID.

TP-Link Omada switch configuration - My main switch is:

TP-Link Omada SG3428XPP-M2

The switch carries multiple working VLANs.

The main OPNsense uplink is: Port 24

This is the trunk carrying the various VLANs between OPNsense and the switch.

The EAP773 access points are connected to: Port 2 and Port 3

The AP ports use the default network for AP management and carry the wireless VLANs as tagged networks. The existing Wi-Fi VLANs are working correctly using this configuration.

When I tested VLAN 90, it was added as a tagged VLAN on:

Port 24 – OPNsense trunk
Port 2 – EAP773
Port 3 – EAP773

Therefore, my expectation was that VLAN 90 traffic should follow the same path as the other working wireless VLANs.

Wireless access points - The access points are: TP-Link Omada EAP773 (I have: 4 × EAP773 Currently two are active).

The CCTV Wi-Fi SSID and most of the configuration on the tp-link hardware was created in Omada controller running on a minisforum MS-A2 in a LXC container in Proxmox and mapped to: VLAN 90

The SSID itself broadcasts correctly.

My iPhone (16 Pro Max) can:

See the SSID but has issues  connecting to the SSID However, it does not receive a DHCP lease. Instead, it eventually receives a: 169.254.x.x self-assigned address.

This appears to indicate that Wi-Fi association is successful, but the DHCP exchange is failing somewhere along the network path.

CCTV infrastructure

My CCTV infrastructure is deliberately separated from the main LAN. The physical CCTV network is connected to a separate physical interface on OPNsense.

The general design is:

IP Cameras
    |
    |
Dahua PoE Switch
    |
    |
Dahua NVR
    |
    |
Dedicated CCTV network
    |
    |
Dedicated physical OPNsense interface

The CCTV switch I currently have is: Dahua PFS3218-16ET-135, This is the 16-port POE Dahua switch.

My NVR is: Dahua DHI-NVR5216-E12

The CCTV network is separate from VLAN 90, located on a seperate port in igc3 (intel i226 quad port)

The purpose of VLAN 90 is not to place cameras directly onto Wi-Fi. Instead, VLAN 90 is intended to provide trusted wireless devices with controlled access to the separate CCTV network.

Conceptually:

CCTV Wi-Fi VLAN
       |
       | Firewall-controlled access
       |
       v
Physical CCTV Network
       |
       +--- Dahua Switch
       |
       +--- IP Cameras
       |
       +--- Dahua DHI-NVR5216-E12

Other parts of my home lab

I also operate a home lab environment that is separated logically from the CCTV infrastructure. I run a Proxmox server hosting various services.

Relevant services include:

Internal DNS
Split DNS
Home lab services
Reverse proxy infrastructure

I use Nginx Proxy Manager as my reverse proxy solution. The internal DNS infrastructure provides split DNS for my internal services.

I mention this for completeness regarding my general network architecture, although I do not believe it is directly related to the DHCP failure because the VLAN 90 client is failing before it even receives an IP address, gateway, or DNS information.

Firewall configuration

For VLAN 90, I created firewall rules intended to control access from the CCTV Wi-Fi network to the separate CCTV network. My initial firewall rule was essentially:

Action:
Pass

Direction:
In

IP Version:
IPv4

Protocol:
Any

Source:
CCTV Wi-Fi network

Destination:
CCTV network

The purpose was to allow trusted devices connected to the CCTV Wi-Fi SSID to reach the CCTV equipment. However, during troubleshooting I began questioning whether this rule could somehow be contributing to the DHCP failure.

My understanding is that the normal client firewall rule should not be the reason a DHCP client cannot obtain its initial lease, because DHCP occurs before the client has an assigned IP address and before normal routed traffic between networks takes place. I therefore did not want to start changing firewall rules randomly without understanding whether they were actually relevant.

Troubleshooting performed so far

I have tried to troubleshoot this by reviewing the configuration at each stage.

1. Confirmed that the SSID is broadcasting The CCTV Wi-Fi SSID is visible. Therefore, the access point is successfully broadcasting the SSID.

2. Confirmed the client does not receive a DHCP lease The client does not receive an address from the VLAN 90 DHCP pool.Instead, it eventually receives: 169.254.x.x This strongly suggests DHCP is not completing.

3. Checked Kea DHCP configuration

• The VLAN 90 interface is configured in OPNsense.
• The VLAN has a dedicated DHCP subnet and pool.
• The relevant VLAN interface is enabled and configured for DHCP service.
• Kea DHCP itself is functioning for my other networks.

4. Checked the OPNsense firewall rules. I created a firewall rule allowing the CCTV Wi-Fi network to access the separate CCTV network. However, because the client is failing before receiving an address, I am unsure whether this rule is relevant to the DHCP issue. I considered changing the destination to: Any to allow general connectivity temporarily, but I did not want to change security policies unnecessarily before identifying where the DHCP failure is occurring.

5. Checked the TP-Link trunk and AP ports. The main uplink/trunk on Port 24 is working for the other VLANs. The EAP773 ports on Ports 2 and 3 are also working for the existing Wi-Fi VLANs. During testing, VLAN 90 was added as a tagged network to the trunk and the AP ports. The configuration otherwise followed the same pattern as the other working wireless VLANs. This is one of the reasons I am struggling to understand why VLAN 90 is behaving differently.

What I have not yet been able to confirm

The critical question I have not yet answered is:

Does the DHCP Discover packet from the VLAN 90 wireless client actually reach the VLAN 90 interface on OPNsense?

The expected path is:

iPhone
   |
   | CCTV Wi-Fi SSID / VLAN 90
   v
EAP773
   |
   | Tagged VLAN 90
   v
Switch Port 2 or 3
   |
   | Tagged VLAN 90
   v
Switch Port 24
   |
   | VLAN trunk
   v
OPNsense VLAN 90 Interface
   |
   v
Kea DHCP

At some point in that path, the DHCP process appears to be failing.

My current thinking

Since the other VLANs work through the same infrastructure, I would like to isolate the problem rather than change multiple settings simultaneously.

I currently have two spare EAP773 access points. I am considering configuring an unused switch port with the same AP trunk configuration and explicitly adding VLAN 90. I would then:

1. Connect a spare EAP773 to the unused port.

2. Configure/test the same CCTV Wi-Fi SSID.

3. Attempt to connect with the iPhone.

4. Check whether DHCP succeeds.

If it works, I could then move the same access point to one of the existing AP ports.

This should help isolate whether the issue is related to:

• The original EAP773 access point
• The existing switch ports
• The Omada configuration
• VLAN 90 tagging
• The trunk
• OPNsense
• Kea DHCP
• Assistance requested

I would appreciate advice on the best logical troubleshooting procedure from here. In particular:

1. What is the best way to capture DHCP traffic on the VLAN 90 interface in OPNsense? I would like to confirm whether OPNsense actually receives the client's DHCP Discover packet. I expect this would immediately divide the problem into two possibilities:

No DHCP Discover reaches OPNsense
        |
        v
Likely AP / switch port / VLAN tagging / trunk issue

or:

DHCP Discover reaches OPNsense
        |
        v
Likely Kea DHCP / VLAN interface / DHCP configuration issue

2. Could the firewall rule on the VLAN interface affect the initial DHCP process? Or should DHCP continue to work independently of the rule controlling access from the CCTV Wi-Fi VLAN to the separate CCTV network?

3. Is there anything specific to Kea DHCP that I should verify when adding a new VLAN interface? Since Kea DHCP works on the other networks, I am wondering if there is a VLAN-specific setting I may have missed.

4. Is there anything specific to TP-Link Omada/EAP VLAN configuration that could allow an SSID to broadcast and accept client associations, but prevent DHCP traffic for that VLAN from reaching the router? This seems particularly relevant because all of my other SSIDs and VLANs work through the same physical equipment. Just a side note , all my Tp-LInk hardware was configured via the omada controller located on my Minisforum MS-A2 running on a LXC in proxmox.

5. Would a packet capture on OPNsense be the best next diagnostic step before changing any configuration? My preference is to identify exactly where the DHCP traffic stops rather than modifying working firewall, switch, or DHCP configurations blindly.

As an additional troubleshooting step, I attempted to perform a packet capture using the built-in OPNsense diagnostics tools. I selected the relevant VLAN/interface and attempted to capture traffic while connecting a client to the CCTV Wi-Fi SSID. However, the resulting PCAP capture file appeared to be blank, with no useful packets captured. This adds another question to the troubleshooting process:

Is DHCP traffic actually reaching the OPNsense VLAN interface at all?

At this stage, I have not been able to determine whether the blank packet capture means: VLAN 90 traffic is not reaching OPNsense or whether: I selected the wrong interface for the packet capture

or

There is another issue with how the packet capture is being performed

Because the other VLANs are functioning correctly, but VLAN 90 clients receive a 169.254.x.x address, I believe confirming whether any DHCP Discover packets from VLAN 90 reach OPNsense is now one of the most important next troubleshooting steps

Thank you in advance to anyone who takes the time to read through this (awfully long)post and offer some advice. I'm still very much learning as I go, so I genuinely appreciate people sharing their experience and pointing me in the right direction.