DHCP relay - process replies (DHCP-Offer, DHCP-Ack...)
Hello, I'm trying to set up a DHCP relay with FreeRADIUS (3.0.15). I've started with the virtual server example "dhcp.relay" provided in the package. The DHCP relaying itself works fine. I would like to do stuff when receiving the response from the server, so I've tried to add this in the virtual server configuration: server dhcp.relay { (...) dhcp DHCP-Offer { linelog_dhcp } dhcp DHCP-Ack { linelog_dhcp } I see this is correctly loaded when the server is started: Thu Oct 12 10:10:55 2017 : Debug: # Loading dhcp DHCP-Offer {...} Thu Oct 12 10:10:55 2017 : Debug: group { Thu Oct 12 10:10:55 2017 : Debug: linelog_dhcp Thu Oct 12 10:10:55 2017 : Debug: } Thu Oct 12 10:10:55 2017 : Debug: # Loading dhcp DHCP-Ack {...} Thu Oct 12 10:10:55 2017 : Debug: group { Thu Oct 12 10:10:55 2017 : Debug: linelog_dhcp Thu Oct 12 10:10:55 2017 : Debug: } However, this is never called when such a message is received. (contrary to "dhcp DHCP-Discover" and "dhcp DHCP-Request" sub-sections) Am I missing something ? Thanks. Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
Actually this seems to be another issue. The DHCP Server is not responding to my FreeRADIUS DHCP relay, but to the previous relay. Not sure why yet, looking into it...
Hello,
I'm trying to set up a DHCP relay with FreeRADIUS (3.0.15). I've started with the virtual server example "dhcp.relay" provided in the package.
The DHCP relaying itself works fine.
I would like to do stuff when receiving the response from the server, so I've tried to add this in the virtual server configuration:
server dhcp.relay { (...) dhcp DHCP-Offer { linelog_dhcp }
dhcp DHCP-Ack { linelog_dhcp }
I see this is correctly loaded when the server is started:
Thu Oct 12 10:10:55 2017 : Debug: # Loading dhcp DHCP-Offer {...} Thu Oct 12 10:10:55 2017 : Debug: group { Thu Oct 12 10:10:55 2017 : Debug: linelog_dhcp Thu Oct 12 10:10:55 2017 : Debug: } Thu Oct 12 10:10:55 2017 : Debug: # Loading dhcp DHCP-Ack {...} Thu Oct 12 10:10:55 2017 : Debug: group { Thu Oct 12 10:10:55 2017 : Debug: linelog_dhcp Thu Oct 12 10:10:55 2017 : Debug: }
However, this is never called when such a message is received. (contrary to "dhcp DHCP-Discover" and "dhcp DHCP-Request" sub-sections) Am I missing something ?
Thanks.
Regards, Nicolas.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On Oct 12, 2017, at 5:46 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
Actually this seems to be another issue. The DHCP Server is not responding to my FreeRADIUS DHCP relay, but to the previous relay.
That's how DHCP works. It's horrible. The DHCP servers respond to the giaddr, not to the source IP of the packet. Alan DeKok.
Actually this seems to be another issue. The DHCP Server is not responding to my FreeRADIUS DHCP relay, but to the previous relay.
That's how DHCP works. It's horrible.
The DHCP servers respond to the giaddr, not to the source IP of the packet.
Yes. But in the virtual server configuration, the giaddr is supposed to be changed: update request { # IP Address of the DHCP relay (ourselves) &DHCP-Gateway-IP-Address := 10.11.19.12 } This doesn't work, however. The network capture shows that giaddr was not changed in the relayed packet. I thought maybe it's because "request" is the initial packet received, so I need to update the "proxy request". So I tried: update proxy-request { # IP Address of the DHCP relay (ourselves) &DHCP-Gateway-IP-Address := 10.11.19.12 } But it doesn't work either, in this case I get the following errors: Thu Oct 12 11:54:25 2017 : WARNING: (0) List "proxy-request" is not available Thu Oct 12 11:54:25 2017 : ERROR: (0) Mapping "10.11.19.12" -> "&DHCP-Gateway-IP-Address" invalid in this context What is the correct way to have FreeRADIUS behave as a DHCP relay ? This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On Oct 12, 2017, at 8:44 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
But in the virtual server configuration, the giaddr is supposed to be changed:
update request { # IP Address of the DHCP relay (ourselves) &DHCP-Gateway-IP-Address := 10.11.19.12 }
That should work... the code path isn't complicated.
This doesn't work, however. The network capture shows that giaddr was not changed in the relayed packet. I thought maybe it's because "request" is the initial packet received, so I need to update the "proxy request".
No, the DHCP relay forwards the original request. It's all a bit backwards.
What is the correct way to have FreeRADIUS behave as a DHCP relay ?
It should work. What does the debug output show? Alan DeKok.
But in the virtual server configuration, the giaddr is supposed to be changed:
update request { # IP Address of the DHCP relay (ourselves) &DHCP-Gateway-IP-Address := 10.11.19.12 }
That should work... the code path isn't complicated.
This doesn't work, however. The network capture shows that giaddr was not changed in the relayed packet. I thought maybe it's because "request" is the initial packet received, so I need to update the "proxy request".
No, the DHCP relay forwards the original request. It's all a bit backwards.
What is the correct way to have FreeRADIUS behave as a DHCP relay ?
It should work. What does the debug output show?
Here goes. Thu Oct 12 16:08:18 2017 : Debug: (1) Received code 1025 Id 1 from 10.11.19.3:67 to 10.11.19.12:67 length 300 Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Opcode = Client-Message Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Hardware-Type = Ethernet Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Hardware-Address-Length = 6 Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Hop-Count = 1 Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Transaction-Id = 1 Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Number-of-Seconds = 0 Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Flags = 0 Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Client-IP-Address = 0.0.0.0 Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Your-IP-Address = 0.0.0.0 Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Server-IP-Address = 0.0.0.0 Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Gateway-IP-Address = 10.11.19.3 Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Client-Hardware-Address = 44:48:42:00:01:01 Thu Oct 12 16:08:18 2017 : Debug: (1) DHCP-Message-Type = DHCP-Discover Thu Oct 12 16:08:18 2017 : Debug: Trying sub-section dhcp DHCP-Discover {...} Thu Oct 12 16:08:18 2017 : Debug: (1) dhcp DHCP-Discover { Thu Oct 12 16:08:18 2017 : Debug: (1) update config { Thu Oct 12 16:08:18 2017 : Debug: (1) &DHCP-Relay-To-IP-Address := 10.11.19.28 Thu Oct 12 16:08:18 2017 : Debug: (1) } # update config = noop Thu Oct 12 16:08:18 2017 : Debug: (1) update request { Thu Oct 12 16:08:18 2017 : Debug: (1) &DHCP-Gateway-IP-Address := 10.11.19.12 Thu Oct 12 16:08:18 2017 : Debug: (1) Overwriting value "10.11.19.3" with "10.11.19.12" Thu Oct 12 16:08:18 2017 : Debug: (1) } # update request = noop Thu Oct 12 16:08:18 2017 : Debug: (1) modsingle[post-auth]: calling ok (rlm_always) Thu Oct 12 16:08:18 2017 : Debug: (1) modsingle[post-auth]: returned from ok (rlm_always) Thu Oct 12 16:08:18 2017 : Debug: (1) [ok] = ok Thu Oct 12 16:08:18 2017 : Debug: (1) } # dhcp DHCP-Discover = ok Sending DHCP-Discover Id 00000001 from 10.11.19.12:67 to 10.11.19.28:67 Thu Oct 12 16:08:18 2017 : Debug: (1) Not sending reply to client. Thu Oct 12 16:08:18 2017 : Debug: (1) Finished request Thu Oct 12 16:08:18 2017 : Debug: (1) Cleaning up request packet ID 1 with timestamp +24 Thu Oct 12 16:08:18 2017 : Info: Ready to process requests This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On Oct 12, 2017, at 10:09 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
It should work. What does the debug output show?
Here goes.
Hmm... not too informative, unfortunately. Are you using 3.0.15? I know this has been deployed in other situations, so I'm not sure what's going on here. Alan DeKok.
Hmm... not too informative, unfortunately.
Are you using 3.0.15? I know this has been deployed in other situations, so I'm not sure what's going on here.
Yes, this is 3.0.15. Should I try with the 3.0.x HEAD ? Or maybe with an older version ? maybe it worked before but got broken at some point. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On Oct 12, 2017, at 11:42 AM, Chaigneau, Nicolas <nicolas.chaigneau@capgemini.com> wrote:
Should I try with the 3.0.x HEAD ? Or maybe with an older version ? maybe it worked before but got broken at some point.
I don't think that code has changed for a long time. You'd have to debug it to see what it's doing. I'd help, but I'm about 6 layers deep in other things right now. Alan DeKok.
Should I try with the 3.0.x HEAD ? Or maybe with an older version ? maybe it worked before but got broken at some point.
I don't think that code has changed for a long time.
You'd have to debug it to see what it's doing.
I'd help, but I'm about 6 layers deep in other things right now.
I understand. At least I know it's supposed to work :) I'll look into it when I have time. I've opened a ticket on GitHub to keep track of this: https://github.com/FreeRADIUS/freeradius-server/issues/2092 Regards, Nicolas. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
participants (2)
-
Alan DeKok -
Chaigneau, Nicolas