• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1520
  • Last Modified:

DHCP Relay Agent Not Forwarding DHCPOFFER

I have written a custom DHCP server intended for the provisioning of SIP handsets.  When tested locally (with broadcast requests), it works perfectly, but when used via a relay agent, the DHCPOFFER messages are not being forwarded from the relay to the client (the DHCPDISCOVER messages arrive at the server just fine).

I have absolutely no idea why this is.  I have eliminated the router as the cause by testing it with several different networks and I can only assume that the problem is due to the contents of the DHCPOFFER message.  Is there a specific way in which these need to be different from a normal broadcast response in order to be accepted?

I've checked the flags, giaddr, hops, lease time (option 51), tried ignoring and echoing option 82, you name it - makes no difference.
0
LordWolfy
Asked:
LordWolfy
  • 7
  • 6
  • 2
1 Solution
 
fmonroyCommented:
I don't know that RFC, but, have you tried to capture and compare packets from both, your DHCP server, and from an "official" DHCP server?
0
 
DeanC30Commented:
The DHCP Discover message is broadcast from the client and picked up by the relay agent, the relay agent then sends a unicast to the DHCP server.  The DHCPOffer is sent as a unicast message from the DHCP server to the relay agent, then the relay agent sends it out as a broadcast.  Your comment "When tested loaccly (with broadcast requests, it works perfectly.."  would indicate that there is not an issue with accepting broadcasts.  Just a thought, and apologies if "sucking eggs" comes to mind!
0
 
LordWolfyAuthor Commented:

Just to clarify: the local / broadcast I was referring to was without a relay agent in which case everything works.

THe unicasts from the relay are picked up correctly.  The unicasts sent back to the relay (DHCPOFFER) never reach the client.
0
Free recovery tool for Microsoft Active Directory

Veeam Explorer for Microsoft Active Directory provides fast and reliable object-level recovery for Active Directory from a single-pass, agentless backup or storage snapshot — without the need to restore an entire virtual machine or use third-party tools.

 
fmonroyCommented:
get ethereal, catch the packets and compare them
0
 
DeanC30Commented:
Gotta agree with fmonroy, ethereal would be my next point of call to identify what is happening
0
 
LordWolfyAuthor Commented:
I have done traces at both ends.  Traffic is fine between the relay and server, but there is definately nothing being returned from the relay to the client.  I have also compared the packets with those from other dhcp servers and theyre identical.  

What else could would cause the packets to be rejected by the relay?
0
 
DeanC30Commented:
Wolfy,  what is your relay agent  (make / model) and any chance we can see one of the packets from the DHCP server to the relay agent  (i.e. one which is not being forwarded after receipt on the relay agent)
0
 
LordWolfyAuthor Commented:
This one is not ideal but it should give you what you need:

http://www.stonewolfsoft.co.uk/projects/sipswitch/dhcptest.pcap (wireshark trace)

Client: Snom 320
Relay: Solwise SAR600EW (192.168.1.1)
Server: Local PC (192.168.1.4)

Because everything here is on the local network the server is set to ignore broadcast packets and only respond to the relay.
0
 
DeanC30Commented:
Cheers Wolfy I will look at it at and get back to you
0
 
LordWolfyAuthor Commented:
I'm upping the points for this as I need an answer soon.
0
 
DeanC30Commented:
Wolfy,  just taking a look at the trace, sorry for the delay.  Just a quick question again apologies if "sucking eggs" comes to mind, you have allowed UDP 67 OUT of the relay on the client side and not just IN on the client?
0
 
DeanC30Commented:
Just looking through the trace, the only thing I can spot is that the IP address being offered is on the same subnet as the DHCPServer, and is received on the interface that would also send it out.  Whereas I would have expected the IP address to be on another subnet.  Not sure how relay agents handle DHCPOffer messages for clients on the same logical subnet as the interface which received it.  I would have thought that the client DHCPOffer would also have been picked up by the DHCP server and would have responded accordingly.  Sorry Wolfy but I can't add anymore to this.

Sorry
0
 
LordWolfyAuthor Commented:
I also tested it on an external server (different network) with the same results.  The reason I'm sticking with the local tests is because its less hassle (have to remote desktop to the other one).

The only other thing I can think of was when I first tested it, my PC's firewall had some issues with UDP checksums - but I dont know how to check that.
0
 
LordWolfyAuthor Commented:
Finally got it working!

I needed to forward incoming traffic on port 67 to 192.168.1.1 (you would think the router would have done that seeing as it was set for relay and all).

DeanC30: What you said about the server being on the same subnet is correct because the above only worked using an external server meaning traffic going straight to 192.169.1.1 from the local network was being ignored - so the points are yours.  Enjoy :)
0
 
DeanC30Commented:
cheers Wolfy, appreciate it.  
0

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 7
  • 6
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now