DHCP NAT (and Relay) and Static Addressing based on Option82/Circuit ID

[Pshem Kowalczyk]

Hi,

I can't comment on the IP address the response should be returned to - we
convinced our BNGs to source all the DHCP-relay packets from a single
loopback.

When it comes to extracting more data from the db we skipped the sqlippool
module completely and use unlang only. Roughly the setup looks like this
(some details relevant to our internal config are stripped here), the same
setup inside DHCP-Discover and DHCP-request:

        update {
            &control:Tmp-String-1 :=
"%{%{string:request:DHCP-Relay-Remote-Id}:-%{string:request:DHCP-Relay-Circuit-Id}}"
        }

        update {
            &control:Tmp-String-0 := "%{frontend_sql:SELECT host(ipaddress)
|| '#' || host(defaultgateway) || '#' || host(netmask(('0.0.0.0/' ||
subnetmask)::inet)) FROM ip, ippool WHERE
ip.username='%{control:Tmp-String-1}'  AND ip.poolname = ippool.poolname
LIMIT 1}"

        }
    }
    if (control:Tmp-String-0 =~ /([0-9\.]+)#([0-9\.]+)#([0-9\.]+)/) {

        update {
            &reply:DHCP-Your-IP-Address := "%{1}"
            &reply:DHCP-Gateway-IP-Address := "%{DHCP-Gateway-IP-Address}"
            &reply:DHCP-Router-Address := "%{2}"
            &reply:DHCP-Subnet-Mask := "%{3}"
            &reply:DHCP-DHCP-Server-Identifier := X.X.X.X
        }
    }

This works since we pre-allocate the IP during the radius phase, when the
session is created, this way the DHCP only has to select an existing IP.
We de-allocate based on radius information (Accounting-Stop) and not on
DHCP-Release (which we quietly ignore).

I don't see any reason why you couldn't do the allocation and de-allocation
in the DHCP server.

kind regards
Pshem


On Tue, 22 Nov 2016 at 19:28 Martin Edge <medge at emersion.com> wrote:

> Hi,
>
> I'm working through setting up FreeRADIUS to behave as a DHCP Server so
> that it can read and respond to DHCP Packets (including Option 82 info).
>
> I'm making progress - however I am facing a few roadblocks that I would
> like some guidance on if possible.
>
> *Packets forwarded from an internal network which are translated out to us
> and carry a DHCP-Relay-IP-Address*
> DHCP Requests that are being sent to us include a Relay-IP-Address - and
> implicitly the DHCP module seems to use this as an authority and attempts
> to return the packet to the Relay IP, not the source of the packet. I was
> able to comment out in the source (3.0.12) - "modules/proto_dhcp/dhcpd.c"
> on line 497 (where it sets a new destination IP address) - and the packet
> was returned to the originator. Obviously this is not the way I should be
> doing this - so any suggestions are welcome.
>
> *DHCP IP Addressing from SQLIPool*
> I have the radippool (via dhcp_sqlippool) process able to extract an IP
> address based on the Circuit ID (Option 82) contained within the DHCP
> Packet.
>
> The challenge I have, is the IP addresses I am allocating (for the same
> provider, but we will also have multiple providers who use our system) -
> has different gateways based on the location of the service and the IP
> allocated. From what I can ascertain looking at the source code, the DHCP
> Pool functionality presently only deals with the returning of the
> Framed-IP-Address.
>
> Looking at "modules/rlm_sqlippool/rlm_sqlippool.c" (line 580) - there is
> an object called 'inst' with a property called framed_ip_address. This is
> used to build a 'vp' and adds it to the reply.
>
> How would one go about providing database driven gateway/dns settings?
>
> Is there a way? Or is the only option to add support for additional
> properties in the code for this? (I would need to isolate where the
> framed_ip_address is mapped to Framed-IP-Address to follow the similar
> behaviour.
>
> Hope you can help!
> Thanks
> Martin.
>
>
>
>
> Martin Edge
> Chief Technical Officer
>
> [Description: Description: Emersion Logo]
> Emersion saves you time and money, by providing an easy to use, secure and
> scalable
> billing, provisioning & operational support system delivered as a service
> in the cloud.
>
> Emersion Software Systems Pty Ltd
> Twitter: .......... @EmersionBilling
>
>
> ________________________________
> This communication may contain CONFIDENTIAL or copyright information of
> Emersion Software Systems Pty Ltd (ABN 28 119 061 791). If you are not an
> intended recipient, you MUST NOT read, print, keep, forward, copy, use,
> save, retransmit or rely on this communication or any attachments, and any
> such action is unauthorised and prohibited. If you have received this
> communication in error, please reply to this e-mail to notify the sender of
> its incorrect delivery, and then delete both it and your reply. Emersion
> does not guarantee the integrity of any emails or any attached files. The
> views or opinions expressed are the author's own and may not reflect the
> views or opinions of Emersion. Thank you.
> ________________________________
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html