Configuring dhcp module in FreeRadius (3.0.2 - Centos 6.5)

Question

I am using the REST module to authorise a DHCP request. I would like to send an explicit DHCP NAK if the authorisation fails, however the DHCP module seems to return immediately if there is a failure and just ignores the DHCP request without any response.

Here is my DHCP module configuration - if rest.authorize is successful, the if (ok) control block is hit, but if rest.authorize fails the if (fail) is never hit.

  dhcp DHCP-Discover {
    rest.authorize

    if (fail) {
            update reply {
                    DHCP-Message-Type = DHCP-Nak
            }
    }

    if (ok) {
        update reply {
           DHCP-Message-Type = DHCP-Offer
        }

        update reply {
            DHCP-Domain-Name-Server = x.x.x.x
            DHCP-Domain-Name-Server = x.x.x.x
            DHCP-Subnet-Mask = 255.255.255.0
            DHCP-Router-Address = x.x.x.x
            DHCP-IP-Address-Lease-Time = 3600
            DHCP-DHCP-Server-Identifier = x.x.x.x
        }
        mac2ip
    }
 }

Below is the output after a 401 Unauthorized is received. I am wanting to achieve a temporary block on DHCP for a specified (small) period of time. However the FreeRADIUS behaviour is to ignore duplicate requests for same DHCP transaction, meaning DHCP on client is blocked until it begins a new transaction. If a DHCP NAK can be sent, the DHCP client will initiate a new transaction after each NAK (i.e. DHCP Discover), meaning FreeRADIUS will process each DHCP Discover from the client, and the block will be removed much closer to the desired block time.

Tue Jun  3 03:00:57 2014 : Debug: (3) rest : Sending HTTP GET to 

"http://xxxxxx//api/v1/dhcp/80%3Aea%3A96%3A2a%3Ab6%3Aaa"
Tue Jun  3 03:00:57 2014 : Debug: (3) rest : Processing response header
Tue Jun  3 03:00:57 2014 : Debug: (3) rest :    Status : 401 (Unauthorized)
Tue Jun  3 03:00:57 2014 : Debug: (3) rest : Skipping attribute processing, no body data received
Tue Jun  3 03:00:57 2014 : Debug: rlm_rest (rest): Released connection (4)
Tue Jun  3 03:00:57 2014 : Debug: (3)   modsingle[authorize]: returned from rest (rlm_rest) for request 3
Tue Jun  3 03:00:57 2014 : Debug: (3)   [rest.authorize] = fail
Tue Jun  3 03:00:57 2014 : Debug: (3)  } # dhcp DHCP-Discover = fail
Tue Jun  3 03:00:57 2014 : Debug: (3) Finished request 3.
Tue Jun  3 03:00:57 2014 : Debug: Waking up in 0.2 seconds.
Tue Jun  3 03:00:58 2014 : Debug: Waking up in 4.6 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:00:59 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:00:59 2014 : Debug: Waking up in 2.9 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:02 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:02 2014 : Debug: Waking up in 0.4 seconds.
Tue Jun  3 03:01:02 2014 : Debug: (2) Cleaning up request packet ID 2064626397 with timestamp +56
Tue Jun  3 03:01:02 2014 : Debug: Waking up in 1999991.0 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:06 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:06 2014 : Debug: Waking up in 3999983.1 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:15 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:15 2014 : Debug: Waking up in 7999966.3 seconds.
Received DHCP-Discover of id 7b0fb2de from 172.19.0.9:67 to 172.19.0.12:67
Tue Jun  3 03:01:23 2014 : Debug: (3) No reply.  Ignoring retransmit.
Tue Jun  3 03:01:23 2014 : Debug: Waking up in 15999942.1 seconds.

On Option #4 solution below, although this works in terms of DHCP NAK, the DHCP module "remembers" the REST authorisation result for the DHCP transaction. Only when the device attempts a new transaction does the DHCP module make the REST authorisation call again:

Received DHCP-Discover of id 7b0fb322 from 172.19.0.9:67 to 172.19.0.12:67
Sending DHCP-NAK of id 7b0fb322 from 172.19.0.12:67 to 172.19.0.9:67
Wed Jun  4 00:31:32 2014 : Debug: Waking up in 3.5 seconds.
Received DHCP-Discover of id 7b0fb322 from 172.19.0.9:67 to 172.19.0.12:67
Sending DHCP-NAK of id 7b0fb322 from 172.19.0.12:67 to 172.19.0.9:67
Wed Jun  4 00:31:35 2014 : Debug: Waking up in 0.6 seconds.
Wed Jun  4 00:31:36 2014 : Debug: (4) Cleaning up request packet ID 2064626465 with timestamp +138
Wed Jun  4 00:31:36 2014 : Debug: Waking up in 1999991.0 seconds.
Received DHCP-Discover of id 7b0fb322 from 172.19.0.9:67 to 172.19.0.12:67
Sending DHCP-NAK of id 7b0fb322 from 172.19.0.12:67 to 172.19.0.9:67
Wed Jun  4 00:31:40 2014 : Debug: Waking up in 3999982.8 seconds.

This is really neat, it's nice to see using the flexibility of the server to do interesting things. — Arran Cudbard-Bell, Jun 02 '14 at 14:30

Arran Cudbard-Bell · Answer 1 · 2014-06-02T16:05:31.387

1

rest.authorize {
    fail = 1
}
if (reject || fail) {
    update reply {
        DHCP-Message-Type = DHCP-NAK
    }
}

OK. So you have four options:

Return a 401 with a JSON content-type and just a set of empty braces {} (that may work)
Use the v3.0.x HEAD commit where i've just altered the behaviour to allow empty bodies. It's odd it's actually calling the body data callback for an empty body. I didn't expect that, which is why it errors out. This will appear in released version 3.0.4.
Edit the return statement just below RDEBUG2("Skipping....") in src/modules/rlm_rest/rest.c to be return 0.
Edit your rest call to match the snippet I added above (because putting it after this bulleted list screwed with the formatting).

edited Jun 02 '14 at 16:05

answered Jun 02 '14 at 14:20

Arran Cudbard-Bell

1,514
1
9
18

I am returning an empty 401 Unauthorized - see added debug output in OP and explanation of the FreeRADIUS DHCP behaviour I am trying to overcome. – mixja Jun 02 '14 at 15:07
I recommend option 4 :) It's actually the correct configuration anyway if you want to NAK requests if your REST API is unavailable. – Arran Cudbard-Bell Jun 02 '14 at 16:07
I found that if I use your suggested solution above ONLY for DHCP Request (not for DHCP Discover), at least on Apple iOS the DHCP behaviour is to create a new DHCP transaction much faster (within 10 seconds) in response to DHCP NAK than if this happens on the DHCP Discover message. – mixja Jun 03 '14 at 12:48

Configuring dhcp module in FreeRadius (3.0.2 - Centos 6.5)

1 Answers1