DHCP failures on MikroTik WiFi VLAN40 typically stem from misconfigured bridge ports, missing DHCP server bindings, or incorrect firewall filter rules blocking DHCP traffic. Verify that the bridge interface includes the wireless interface and VLAN interface, ensure the DHCP server is bound to the correct network, and check for any active firewall drops on UDP ports 67 and 68.
Verifying Bridge Interface Configuration
The most common cause of DHCP failure in a VLAN setup on MikroTik RouterOS is an improperly configured bridge. The bridge acts as the virtual switch that connects your physical ports, wireless interfaces, and VLAN sub-interfaces. If the wireless interface or the VLAN40 interface is not added as a member of the bridge, DHCP requests from clients cannot reach the DHCP server running on the router. First, inspect your current bridge configuration using the terminal command/interface bridge print. Ensure that the bridge interface (often named bridge-local or similar) exists and is enabled. Next, check the members of this bridge by running /interface bridge port print. You must see both the wireless interface (e.g., wlan1) and the VLAN40 interface (e.g., vlan40) listed as members. If either is missing, add them using /interface bridge port add bridge=bridge-local interface=wlan1 and similarly for the VLAN interface. Without this connection, the broadcast packets containing DHCP Discover messages are isolated from the server side of the network.
It is also crucial to verify that the PVID (Port VLAN ID) settings on the bridge ports align with your network design. If you are tagging traffic, ensure the wireless SSID is correctly configured to tag frames with VLAN ID 40. In the wireless security profiles or interface settings, confirm that the VLAN ID matches the one created on the router. A mismatch here results in clients sending untagged or incorrectly tagged frames that the bridge drops or misroutes, preventing them from reaching the DHCP scope.
Checking DHCP Server and Lease Settings
Even with a perfect bridge configuration, the DHCP server itself may be misconfigured. Navigate to/ip dhcp-server and list your servers. You should see a server associated with the VLAN40 network range. Check the network field to ensure it matches the subnet assigned to VLAN40 (for example, 192.168.40.0/24). If the network address is incorrect, the server will not offer addresses to clients on that specific VLAN.
Additionally, examine the lease-time and address-pool settings. An exhausted address pool can cause new devices to fail to obtain an IP. Use /ip dhcp-server lease print to view active leases. If all addresses are leased out and no dynamic pool remains, consider increasing the pool size or reducing the lease time. Also, verify that the interface parameter in the DHCP server configuration explicitly points to the VLAN40 interface or the bridge interface that carries VLAN40 traffic. Binding the server to the wrong interface, such as the main LAN interface, will prevent it from responding to broadcasts arriving on VLAN40.
Another subtle issue involves the use-src-mac setting. While rarely the primary cause of total failure, ensuring consistent MAC-based reservations can help if you suspect duplicate IP conflicts. However, for initial troubleshooting, focus on the basic network binding and pool availability. If the server is disabled or set to disabled=yes, obviously no IPs will be assigned. Ensure the status is enabled.
Inspecting Firewall Rules
MikroTik’s default firewall configuration often includes strict rules that can inadvertently block DHCP traffic, especially when dealing with multiple VLANs. Check the input chain in the firewall filter by running/ip firewall filter print. Look for rules that drop or reject traffic. Specifically, verify that there are no rules dropping UDP ports 67 (server) and 68 (client).
Sometimes, administrators add custom rules to secure the management interface or restrict inter-VLAN communication. These rules might apply to the input chain but affect DHCP if the DHCP server runs locally on the router. Ensure that the rule allowing DHCP traffic permits connections from the VLAN40 network. If you have a rule that allows established connections but drops new ones without explicit exceptions, DHCP handshakes (which are stateless in their initial discovery phase) might be blocked.
Also, review the NAT section under /ip firewall nat. While NAT does not directly stop DHCP discovery, improper masquerading rules can cause issues if the DHCP relay is involved. However, in a standard local DHCP setup, the filter rules are the primary suspect. If you recently modified firewall policies, revert them to defaults temporarily to test if DHCP begins working, then gradually reapply rules to identify the culprit.
Testing and Diagnostics
To isolate the issue further, use packet capture tools. Enable packet sniffing on the VLAN40 interface to see if DHCP Discover packets are leaving the client and if DHCP Offer packets are returning. This confirms whether the problem lies in the client-to-router path or the router-to-client response. Additionally, try assigning a static IP to a client device within the VLAN40 subnet. If the client can ping the router’s gateway IP but cannot get DHCP, the issue is strictly with the DHCP service or its binding. If the static IP fails to communicate, the problem is likely at the bridge or firewall level, preventing any layer 3 connectivity. For persistent issues, consult related guides on general DHCP troubleshooting and WiFi connectivity problems to ensure no broader network configuration errors exist.Frequently Asked Questions
Why do devices get APIPA addresses like 169.254.x.x?
This indicates the device failed to receive a DHCP offer and defaulted to Automatic Private IP Addressing. It usually means the DHCP request was dropped by a firewall rule or never reached the server due to a bridge misconfiguration. Check for UDP port 67/68 blocks and verify bridge member inclusion.
Can I use DHCP Relay instead of a local DHCP server?
Yes, if your DHCP server resides on a different subnet or router, you must enable DHCP Relay on the VLAN40 interface. Configure the relay agent to point to the IP address of the remote DHCP server. This ensures broadcast requests are forwarded as unicasts to the correct server.
What happens if the DHCP lease pool is full?
New clients will not receive IP addresses and will remain stuck in the "Obtaining IP address" state. Existing clients may lose connectivity if their leases expire and they cannot renew. Increase the address pool size or reduce the lease duration to accommodate more devices.
Does enabling IPv6 affect IPv4 DHCP?
No, IPv6 uses SLAAC or DHCPv6 and operates independently of IPv4 DHCP. However, if you have strict firewall rules that drop all non-essential traffic, ensure you haven't inadvertently blocked IPv4 UDP ports while configuring IPv6 rules. They do not interfere with each other directly.
How do I clear stale DHCP leases?
You can remove all active leases by running /ip dhcp-server lease remove [find] in the terminal. This forces connected clients to request new leases immediately upon reconnecting, which can resolve issues where the server has lost track of valid assignments.