"Recent posts
#1
Tutorials and FAQs / Re: [HOWTO] NordVPN Wireguard ...
Last post by MagikMark - Today at 01:16:55 AMThanks for the guide. May I ask why SNAT? Most guides use Outbound NAT and works perfectly as well
#2
General Discussion / GeoIP database fails to load
Last post by jimk2152 - Today at 12:33:00 AMProblem:
The GUI fails to download the MaxMind GeoIP database even though the database will download using a browser and it was working.
Persistent error message warning that GeoIP database needs to be downloaded.
Fix that worked for me:
Disable any Firewall GeoIP alias and Apply (Firewall -> Aliases - uncheck any GeoIP aliases)
Select GeoIP Settings tab
Select the MaxMind URL and copy the URL text, then delete the URL text
Press Apply
Select Aliases tab
Reenable the Firewall GeoIP alias and Apply
Select GeoIP Settings tab
Paste the copied MaxMind URL
Press Apply
Page will refresh and should show something like this:
Last updated 2026-08-28T16:13:46
Last updated timestamp. This is the time the vendor created the lists.
Total number of ranges 1091328
Total number of entries in downloaded set.
Make sure Chron is set up to Update and Reload Firewall Aliases (daily if necessary)
The GUI fails to download the MaxMind GeoIP database even though the database will download using a browser and it was working.
Persistent error message warning that GeoIP database needs to be downloaded.
Fix that worked for me:
Disable any Firewall GeoIP alias and Apply (Firewall -> Aliases - uncheck any GeoIP aliases)
Select GeoIP Settings tab
Select the MaxMind URL and copy the URL text, then delete the URL text
Press Apply
Select Aliases tab
Reenable the Firewall GeoIP alias and Apply
Select GeoIP Settings tab
Paste the copied MaxMind URL
Press Apply
Page will refresh and should show something like this:
Last updated 2026-08-28T16:13:46
Last updated timestamp. This is the time the vendor created the lists.
Total number of ranges 1091328
Total number of entries in downloaded set.
Make sure Chron is set up to Update and Reload Firewall Aliases (daily if necessary)
#3
General Discussion / Re: nfSensei ( fork pfsense )
Last post by muchacha_grande - Today at 12:15:43 AMQuote from: sopex on Today at 12:02:02 AM2) The guy has spent the last 15 years as a generic IT guy in marketing organizations.
This is the key: "Marketing"
#4
General Discussion / Re: nfSensei ( fork pfsense )
Last post by sopex - Today at 12:02:02 AMIf he actually ships anything I will be more than surprised.
1) His LinkedIn very clearly states that nfSensei started when he left his last job on December of 2025, which is more believable than 2024 since the domain was registered late January 2026.
2) The guy has spent the last 15 years as a generic IT guy in marketing organizations. To the best of my knowledge without any coding projects on the side.
3) The AI coded site has the most nonsensical AI generated content I have read in years.
4) How can one have an open source project without sharing the source in any way? Especially in the beginning, feedback is very important.
1) His LinkedIn very clearly states that nfSensei started when he left his last job on December of 2025, which is more believable than 2024 since the domain was registered late January 2026.
2) The guy has spent the last 15 years as a generic IT guy in marketing organizations. To the best of my knowledge without any coding projects on the side.
3) The AI coded site has the most nonsensical AI generated content I have read in years.
4) How can one have an open source project without sharing the source in any way? Especially in the beginning, feedback is very important.
#5
General Discussion / Re: nfSensei ( fork pfsense )
Last post by Netlearn - August 31, 2026, 11:37:22 PMQuote from: Bob.Dig on August 31, 2026, 08:21:46 PMQuote from: Netlearn on August 31, 2026, 01:31:53 PMHereHere what, you were wrong, about twenty years.
Yup! I made a typo in the first date. I meant 2024.
The line was "Here: About", being "About" the link to his curriculum description. Maybe easy to overlook. Apologies.
#6
Development and Code Review / Re: netflector available as pl...
Last post by UnicronHD - August 31, 2026, 10:52:12 PMQuote from: franco on August 14, 2026, 09:29:59 AMNice work indeed! If upstream gives you trouble we can consider integrating via our ports tree. Just let me know in a couple of weeks how this progresses.
Update (because more than two weeks have passed): I got absolutely no reaction to my new port suggestion. On the bright side: it was not rejected :) So I guess I'll keep waiting...
#7
General Discussion / DHCP Issues on VLAN 90 with OP...
Last post by 350flyer - August 31, 2026, 10:15:40 PMHello 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:
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:
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:
The current software versions are:
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
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:
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.
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:
QuoteVLAN 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:
Quote169.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:
QuoteLenovo ThinkCentre M920Q Tiny
Intel Core i7-9700T
32 GB RAM
1 TB SSD
Intel i226 quad-port Ethernet adapter
The current software versions are:
QuoteOPNsense 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.
#8
26.7 Series / Re: OpenVPN DCO mode triggerin...
Last post by whatever - August 31, 2026, 10:15:38 PMThe same errors appear when running netstat and are also visible in Interfaces > Diagnostics > Netstat. I feel there's a strong possibility this is just cosmetic, as there are many reports online about how DCO reports interface stats differently from TUN mode, which may result in a higher error count. But seeing those errors tick up just makes me feel as if something is misconfigured on my end...
#9
General Discussion / Re: nfSensei ( fork pfsense )
Last post by pfry - August 31, 2026, 10:04:52 PMQuote from: Greg_E on August 31, 2026, 08:13:24 PMIt is interesting, especially VPP support. Routing across local LANs at 10g with less overhead would be nice, something I may start doing in my lab just to see what the results might be. My current lab OPN device has a quad port x710 card installed, so I could get 3 LAN all going at 10g if I wanted to test it, WAN is still very limited.
I know this doesn't apply to you, but for others who want to try DPDK-based software like VPP or DANOS: you definitely need recent firmware for Intel cards, as DPDK uses (at least by default) every hardware bell and whistle offered by the driver. I don't know about Aquantia/Marvell devices; I haven't used Mellanox/nVidia or newer Broadcom devices; Chelsio includes firmware in their (gigantic) driver.
DANOS requires much less investment to set up (or did, at least - VPP may have improved since I used it), but is dead like rock. (I don't even know whether Ciena still maintains Vyatta, as they closed off the docs.) VyOS may be an convenient option (for testing VPP), but I haven't looked at it recently either.
#10
Virtual private networks / Re: Wireguard and Documentatio...
Last post by FredFresh - August 31, 2026, 10:04:46 PMI was looking on the net for a guide...and I was missing the "migration assistant" exactly a line above the NAT menu.
Thanks.
Thanks.
