DHCP Relay Agent Not Working – 3 Fixes That Actually Work

1. The helper-address is missing or wrong

This is the #1 reason DHCP relay agents fail. I've seen it on Cisco switches, Juniper routers, and even Linux boxes. The relay agent needs a specific command to know where to send DHCP requests. Without it, the DHCP Discover packet just hits the broadcast domain and dies.

On a Cisco device, you use ip helper-address under the interface facing the DHCP clients. The syntax is simple:

interface Vlan10
 ip address 192.168.10.1 255.255.255.0
 ip helper-address 192.168.200.10

That 192.168.200.10 is the DHCP server. People sometimes use the server’s gateway IP by accident. Or they forget to add the command at all. Double-check that the helper-address points to the actual DHCP server, not some random IP.

On a Windows Server running DHCP relay (the Routing and Remote Access role), you configure it through the DHCP Relay Agent snap-in. Right-click, add a new server, and type the IP. Then under Interfaces, you must enable DHCP relay on the correct interface. Miss that step and the relay agent sits idle.

Most common mistake: putting the helper-address on the wrong VLAN interface. The DHCP client's broadcast must hit that interface first. If it's on the server-side interface, it won't work. Example: clients are on VLAN 10, server is on VLAN 20. The helper-address goes under interface Vlan10, not Vlan20.

2. Interface-level filtering or ACLs blocking DHCP traffic

Even with the correct helper-address, the relay agent can't forward packets if an ACL or firewall rule drops them. DHCP uses UDP ports 67 (server) and 68 (client). The relay agent listens on UDP 67 and forwards to the server on UDP 67. But if there's an ACL on the interface that blocks UDP 67/68, you're dead in the water.

I've seen this on Cisco switches with VACLs (VLAN ACLs) or port ACLs. Someone locked down the VLAN to prevent rogue DHCP servers, and accidentally blocked the relay traffic too. Check with:

show access-lists
show ip interface Vlan10

Look for any deny udp any any eq 67 or deny udp any any eq 68. If you find one, either remove it or add an permit statement before the deny. Remember: ACLs process top-down, so order matters.

On Windows, check Windows Firewall. The DHCP Relay Agent service uses UDP 67. Windows Firewall often blocks inbound UDP 67 by default. Add a rule to allow it. Don't bother disabling the firewall entirely – that's lazy and insecure. Just open the port.

Another weird one: switches with DHCP snooping enabled. DHCP snooping is great for security, but it can interfere with relay agents. If the relay agent itself is not a trusted DHCP snooping source, the switch drops the packets. On Cisco, add the relay agent interface as a trusted port:

interface GigabitEthernet0/1
 ip dhcp snooping trust

On Juniper, it's similar. set forwarding-options dhcp-relay server-group configs need no ACL blocking. Check with show firewall.

3. DHCP server doesn't have a route back to the relay agent

This one's sneaky. The relay agent forwards the DHCP Discover to the server. The server sends back a DHCP Offer. But if the server doesn't have a route back to the relay agent's IP, the Offer never arrives. And the client never gets an IP.

The relay agent uses its own IP (the interface IP where the helper-address is configured) as the source address when forwarding. So the DHCP server sees the request coming from, say, 192.168.10.1 (the relay agent's VLAN interface). The server sends the DHCP Offer to 192.168.10.1. But if the server's default gateway doesn't know how to reach 192.168.10.0/24, the packet gets dropped.

Fix: add a static route on the DHCP server or its next-hop router. For example, if the server is on 10.0.0.0/24 and the relay agent is on 192.168.10.1, you need:

route add 192.168.10.0 mask 255.255.255.0 10.0.0.1

On a Linux DHCP server (like ISC DHCP), also verify that subnet declarations match the relay agent's subnet. ISC DHCP needs a subnet block even if the server isn't directly connected. Example:

subnet 192.168.10.0 netmask 255.255.255.0 {
    option routers 192.168.10.1;
}

Without that, the server might refuse to send offers. I've wasted hours on that one.

On Windows DHCP, you don't need a subnet declaration. But you do need a scope for the relayed subnet. If the scope for 192.168.10.0 doesn't exist, the server has no IPs to give. Authorize the server in AD too – an unauthorized DHCP server silently drops requests.

One more edge case: the relay agent and DHCP server are on different VLANs with no routing between them. That's a network design problem. Put the relay agent on the same L3 interface as the clients, or use a separate relay agent per subnet.

Quick-reference summary table