Freeradius Proxy - Framed IP Address Accounting attribute
Hi All We are trailing a wifi system that does not send through the Framed IP Address attribute to our accounting server after the clients have successfully authenticated (EAP-PEAP-MSCHAP authentication) against a FreeRadius server hosted at another site within our WAN. I am of the mindset of setting up a Freeradius proxy server locally onsite with the purpose of sending back an accounting start with the Framed IP Address attribute to the accounting server but am unsure if this is even possible as I am unsure if the freeradius server would be able to determine the clients IP address as only the clients MAC address is passed to the radius server during authentication. I was unable to find any documentation that would support this, and would hope that someone could point me in the right direction. - Regards - Byron
On 11 June 2017 10:41:32 BST, Byron Jeffery <byronjeffery@cem.org.au> wrote:
We are trailing a wifi system that does not send through the Framed IP Address attribute to our accounting server after the clients have successfully authenticated
That's not particularly useful. Some NASes send the IP later in an Interim-Update. Have you checked that?
I am of the mindset of setting up a Freeradius proxy server locally onsite with the purpose of sending back an accounting start with the Framed IP Address attribute to the accounting server but am unsure if this is even possible
Not sure where you expect the proxy server to get the data from if the NAS never sent it in the first place. You need to fix the NAS, or look at another place to get the IP address from such as the DHCP logs. If the NAS can't be fixed now might be a good time to trial a different wireless system if you need that functionality... -- Matthew
Thanks Matthew Yep, you are correct in that it is not particularly usefully to not have that feature. I will check if the NAS follows through with an interim update but don't really recall seeing any later packets coming through. It is a known issue with the NAS which I only discovered during the trial, hence me putting out the question regarding the proxy. Regarding you mentioning getting the IP address from the DHCP logs, is there known way to do such? May need to look at other systems as we need accounting for our content filter system. Thanks for the input once again. - Regards - Byron On Sun, Jun 11, 2017 at 8:08 PM, Matthew Newton <mcn@freeradius.org> wrote:
On 11 June 2017 10:41:32 BST, Byron Jeffery <byronjeffery@cem.org.au> wrote:
We are trailing a wifi system that does not send through the Framed IP Address attribute to our accounting server after the clients have successfully authenticated
That's not particularly useful.
Some NASes send the IP later in an Interim-Update. Have you checked that?
I am of the mindset of setting up a Freeradius proxy server locally onsite with the purpose of sending back an accounting start with the Framed IP Address attribute to the accounting server but am unsure if this is even possible
Not sure where you expect the proxy server to get the data from if the NAS never sent it in the first place.
You need to fix the NAS, or look at another place to get the IP address from such as the DHCP logs.
If the NAS can't be fixed now might be a good time to trial a different wireless system if you need that functionality...
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On 11 June 2017 11:38:31 BST, Byron Jeffery <byronjeffery@cem.org.au> wrote:
Regarding you mentioning getting the IP address from the DHCP logs, is there known way to do such?
Use FreeRADIUS as your DHCP server, and store the data in the same database? Or run a script to parse the logs and push into a DB? Or feed everything into something like elasticsearch as well as your accounting DB and query the combined logs there. Three ways I can think of off the top of my head.
May need to look at other systems as we need accounting for our content filter system.
Complain to the vendor before you buy? And don't commit to buy until they have actually released the fixed code. I've hardly ever seen vendor promises filled once they've got your money... but you've got some leverage now. -- Matthew
Hi Matthew I have been doing some research on the Freeradius DHCP and from what I could tell would I be correct in saying that the Freeradius DHCP service is a static DHCP service? - Kind Regards - Byron Jeffery - ICT Helpdesk Coordinator ------------------------------ - Phone:0243636107 - Mobile:043 230 7030 - Fax:(07) 3889 7245 - Office:Suite 304, 200 The Central Coast Hwy, Erina NSW 2250 - Postal:PO Box 3101, Caboolture BC QLD 4510 ------------------------------ The content of this message is provided without responsibility in law for their accuracy or otherwise, and without assumption of a duty of care by Australian Christian College. Whilst every attempt has been made to ensure that material contained in this email is free from computer viruses or other defects, the attached files are provided, and may only be used, on the basis that the user assumes all responsibility for use of the material transmitted. This email is intended only for the use of the individual or entity names above and may contain information that is confidential and privileged. If you are not the intended recipient, please note that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email and destroy the original message. On Sun, Jun 11, 2017 at 8:46 PM, Matthew Newton <mcn@freeradius.org> wrote:
On 11 June 2017 11:38:31 BST, Byron Jeffery <byronjeffery@cem.org.au> wrote:
Regarding you mentioning getting the IP address from the DHCP logs, is there known way to do such?
Use FreeRADIUS as your DHCP server, and store the data in the same database? Or run a script to parse the logs and push into a DB? Or feed everything into something like elasticsearch as well as your accounting DB and query the combined logs there.
Three ways I can think of off the top of my head.
May need to look at other systems as we need accounting for our content filter system.
Complain to the vendor before you buy? And don't commit to buy until they have actually released the fixed code. I've hardly ever seen vendor promises filled once they've got your money... but you've got some leverage now.
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Tue, Jun 20, 2017 at 04:35:28PM +1000, Byron Jeffery wrote:
I have been doing some research on the Freeradius DHCP and from what I could tell would I be correct in saying that the Freeradius DHCP service is a static DHCP service?
Well, I'm guessing you don't move the servers around too much... :) But no, you can do dynamic DHCP. See sites-enabled/dhcp, the section that is commented out for dhcp_sqlippool (which also uses policies from policy.d/dhcp). It's a bit more low-level than, say, ISC dhcpd. Less tested as there's less usage (it is being used in live deployments) but far more flexible. dhcpd doesn't let you store your leases in a database, for example. -- Matthew
On 20 Jun 2017, at 07:14, Matthew Newton <matthew@newtoncomputing.co.uk> wrote:
On Tue, Jun 20, 2017 at 04:35:28PM +1000, Byron Jeffery wrote:
I have been doing some research on the Freeradius DHCP and from what I could tell would I be correct in saying that the Freeradius DHCP service is a static DHCP service?
Well, I'm guessing you don't move the servers around too much... :)
But no, you can do dynamic DHCP. See sites-enabled/dhcp, the section that is commented out for dhcp_sqlippool (which also uses policies from policy.d/dhcp).
It's a bit more low-level than, say, ISC dhcpd. Less tested as there's less usage (it is being used in live deployments) but far more flexible. dhcpd doesn't let you store your leases in a database, for example.
The DHCP server is used by multiple ISPs servicing a large, heterogeneous client base. It’s pretty well tested :) -Arran
On Tue, Jun 20, 2017 at 08:21:44AM -0400, Arran Cudbard-Bell wrote:
On 20 Jun 2017, at 07:14, Matthew Newton <matthew@newtoncomputing.co.uk> wrote: It's a bit more low-level than, say, ISC dhcpd. Less tested as there's less usage (it is being used in live deployments) but far more flexible. dhcpd doesn't let you store your leases in a database, for example.
The DHCP server is used by multiple ISPs servicing a large, heterogeneous client base. It’s pretty well tested :)
Yeah, that didn't come over well. "Less tested" and "less usage" not implying that it's no good, just hasn't seen as many years as ISC dhcpd. But every time I use ISC dhcpd (especially failover) I usually end up wanting to die, so having something with proper database support is good. :) -- Matthew
Thanks Matthew and Arran I'll keep plugging away at it :-) - Kind Regards - Byron Jeffery - ICT Helpdesk Coordinator ------------------------------ - Phone:0243636107 - Mobile:043 230 7030 - Fax:(07) 3889 7245 - Office:Suite 304, 200 The Central Coast Hwy, Erina NSW 2250 - Postal:PO Box 3101, Caboolture BC QLD 4510 ------------------------------ The content of this message is provided without responsibility in law for their accuracy or otherwise, and without assumption of a duty of care by Australian Christian College. Whilst every attempt has been made to ensure that material contained in this email is free from computer viruses or other defects, the attached files are provided, and may only be used, on the basis that the user assumes all responsibility for use of the material transmitted. This email is intended only for the use of the individual or entity names above and may contain information that is confidential and privileged. If you are not the intended recipient, please note that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email and destroy the original message. On Wed, Jun 21, 2017 at 12:42 AM, Matthew Newton < matthew@newtoncomputing.co.uk> wrote:
On Tue, Jun 20, 2017 at 08:21:44AM -0400, Arran Cudbard-Bell wrote:
On 20 Jun 2017, at 07:14, Matthew Newton < matthew@newtoncomputing.co.uk> wrote: It's a bit more low-level than, say, ISC dhcpd. Less tested as there's less usage (it is being used in live deployments) but far more flexible. dhcpd doesn't let you store your leases in a database, for example.
The DHCP server is used by multiple ISPs servicing a large, heterogeneous client base. It’s pretty well tested :)
Yeah, that didn't come over well. "Less tested" and "less usage" not implying that it's no good, just hasn't seen as many years as ISC dhcpd.
But every time I use ISC dhcpd (especially failover) I usually end up wanting to die, so having something with proper database support is good. :)
-- Matthew - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
Hi Matthew I have successfully managed to get the Freeradius DHCP server with a single subnet linked to MySQL radius database. However, I have been stumped by an issue whereby a wireshark capture shows the client sending out a DHCP Discover, the Freeradius DHCP server replying with a DHCP-Offer with the correct IP address, but am not seeing the Offer in the wireshark capture and hence the client not receiving the IP address allocation. My freeradius version is 3.0.12. I am unsure of where else to look and was wondering if you may have any further suggestions. - Kind Regards - Byron Jeffery - ICT Helpdesk Coordinator ------------------------------ - Phone:0243636107 - Mobile:043 230 7030 - Fax:(07) 3889 7245 - Office:Suite 304, 200 The Central Coast Hwy, Erina NSW 2250 - Postal:PO Box 3101, Caboolture BC QLD 4510 ------------------------------ The content of this message is provided without responsibility in law for their accuracy or otherwise, and without assumption of a duty of care by Australian Christian College. Whilst every attempt has been made to ensure that material contained in this email is free from computer viruses or other defects, the attached files are provided, and may only be used, on the basis that the user assumes all responsibility for use of the material transmitted. This email is intended only for the use of the individual or entity names above and may contain information that is confidential and privileged. If you are not the intended recipient, please note that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email and destroy the original message. On Wed, Jun 21, 2017 at 4:44 PM, Byron Jeffery <byronjeffery@cem.org.au> wrote:
Thanks Matthew and Arran
I'll keep plugging away at it :-)
- Kind Regards
- Byron Jeffery - ICT Helpdesk Coordinator
------------------------------
- Phone:0243636107 - Mobile:043 230 7030 - Fax:(07) 3889 7245 - Office:Suite 304, 200 The Central Coast Hwy, Erina NSW 2250 - Postal:PO Box 3101, Caboolture BC QLD 4510
------------------------------
The content of this message is provided without responsibility in law for their accuracy or otherwise, and without assumption of a duty of care by Australian Christian College. Whilst every attempt has been made to ensure that material contained in this email is free from computer viruses or other defects, the attached files are provided, and may only be used, on the basis that the user assumes all responsibility for use of the material transmitted. This email is intended only for the use of the individual or entity names above and may contain information that is confidential and privileged. If you are not the intended recipient, please note that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email and destroy the original message.
On Wed, Jun 21, 2017 at 12:42 AM, Matthew Newton < matthew@newtoncomputing.co.uk> wrote:
On Tue, Jun 20, 2017 at 08:21:44AM -0400, Arran Cudbard-Bell wrote:
On 20 Jun 2017, at 07:14, Matthew Newton < matthew@newtoncomputing.co.uk> wrote: It's a bit more low-level than, say, ISC dhcpd. Less tested as there's less usage (it is being used in live deployments) but far more flexible. dhcpd doesn't let you store your leases in a database, for example.
The DHCP server is used by multiple ISPs servicing a large, heterogeneous client base. It’s pretty well tested :)
Yeah, that didn't come over well. "Less tested" and "less usage" not implying that it's no good, just hasn't seen as many years as ISC dhcpd.
But every time I use ISC dhcpd (especially failover) I usually end up wanting to die, so having something with proper database support is good. :)
-- Matthew - List info/subscribe/unsubscribe? See http://www.freeradius.org/list /users.html
On Jul 12, 2017, at 2:21 AM, Byron Jeffery <byronjeffery@cem.org.au> wrote:
I have successfully managed to get the Freeradius DHCP server with a single subnet linked to MySQL radius database.
That's good.
However, I have been stumped by an issue whereby a wireshark capture shows the client sending out a DHCP Discover, the Freeradius DHCP server replying with a DHCP-Offer with the correct IP address, but am not seeing the Offer in the wireshark capture
What wireshark capture? Where? There isn't much magic here. If FreeRADIUS sends a packet, it relies on the OS to send the packet. If the packet disappears... blame the OS / routing, not FreeRADIUS.
and hence the client not receiving the IP address allocation. My freeradius version is 3.0.12. I am unsure of where else to look and was wondering if you may have any further suggestions.
Track the packet out the interface that FreeRADIUS is using. Then, track the packet hop by hop across the network. Note that wireshark on the same machine MIGHT NOT see the outgoing packet. It all depends on how the local network stack works. Alan DeKok.
Hi I have managed to resolve the issue with the client not receiving the DHCP Offer as I may have set something in the config somewhere that was causing the freeradius dhcp to return an offer to the gateway and not as a broadcast. I decided to start again and that resolved that issue. Following from that, I would like to setup DHCP for multiple subnets/vlans, however, is it recommended to setup a separate dhcp virtual server per vlan or do a switch statement in the DHCP conf file switching to the relevant ippool per vlan? - Kind Regards - Byron Jeffery - ICT Helpdesk Coordinator ------------------------------ - Phone:0243636107 - Mobile:043 230 7030 - Fax:(07) 3889 7245 - Office:Suite 304, 200 The Central Coast Hwy, Erina NSW 2250 - Postal:PO Box 3101, Caboolture BC QLD 4510 ------------------------------ The content of this message is provided without responsibility in law for their accuracy or otherwise, and without assumption of a duty of care by Australian Christian College. Whilst every attempt has been made to ensure that material contained in this email is free from computer viruses or other defects, the attached files are provided, and may only be used, on the basis that the user assumes all responsibility for use of the material transmitted. This email is intended only for the use of the individual or entity names above and may contain information that is confidential and privileged. If you are not the intended recipient, please note that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email and destroy the original message. On Wed, Jul 12, 2017 at 10:04 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 12, 2017, at 2:21 AM, Byron Jeffery <byronjeffery@cem.org.au> wrote:
I have successfully managed to get the Freeradius DHCP server with a single subnet linked to MySQL radius database.
That's good.
However, I have been stumped by an issue whereby a wireshark capture shows the client sending out a DHCP Discover, the Freeradius DHCP server replying with a DHCP-Offer with the correct IP address, but am not seeing the Offer in the wireshark capture
What wireshark capture? Where?
There isn't much magic here. If FreeRADIUS sends a packet, it relies on the OS to send the packet. If the packet disappears... blame the OS / routing, not FreeRADIUS.
and hence the client not receiving the IP address allocation. My freeradius version is 3.0.12. I am unsure of where else to look and was wondering if you may have any further suggestions.
Track the packet out the interface that FreeRADIUS is using. Then, track the packet hop by hop across the network.
Note that wireshark on the same machine MIGHT NOT see the outgoing packet. It all depends on how the local network stack works.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Jul 20, 2017, at 2:41 AM, Byron Jeffery <byronjeffery@cem.org.au> wrote:
Following from that, I would like to setup DHCP for multiple subnets/vlans, however, is it recommended to setup a separate dhcp virtual server per vlan or do a switch statement in the DHCP conf file switching to the relevant ippool per vlan?
It's probably simplest. Alan DeKok.
Hi all I currently have a test FreeRadius server setup for authentication (local user file) and DHCP which is working as intended, however, I am trying to implement a solution whereby the Framed IP Address attribute and username is sent to an accounting server at some point during or after the authentication process. My understanding is that after the user successfully authenticates, the client device then proceeds to obtain an IP address from the DHCP, however, am I correct in saying that if I wish to obtain the Framed IP Address, I will not be able to obtain this after the authentication (ie: post-auth). If so, am I able to make a call to the dhcp_sqlippool to get an IP during the post-auth process or is there a better alternative method to do this? - Kind Regards - Byron Jeffery - On Thu, Jul 20, 2017 at 10:30 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 20, 2017, at 2:41 AM, Byron Jeffery <byronjeffery@cem.org.au> wrote:
Following from that, I would like to setup DHCP for multiple subnets/vlans, however, is it recommended to setup a separate dhcp virtual server per vlan or do a switch statement in the DHCP conf file switching to the relevant ippool per vlan?
It's probably simplest.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Aug 1, 2017, at 8:21 AM, Byron Jeffery <byronjeffery@cem.org.au> wrote:
I currently have a test FreeRadius server setup for authentication (local user file) and DHCP which is working as intended, however, I am trying to implement a solution whereby the Framed IP Address attribute and username is sent to an accounting server at some point during or after the authentication process.
The NAS is responsible for sending accounting packets. If you want something in the accounting packets, see the NAS documentation.
My understanding is that after the user successfully authenticates, the client device then proceeds to obtain an IP address from the DHCP,
Yes. And the DHCP address assignment has pretty much nothing to do with RADIUS.
however, am I correct in saying that if I wish to obtain the Framed IP Address, I will not be able to obtain this after the authentication (ie: post-auth).
post-auth runs before the Access-Accept is sent back. If the IP is assigned via DHCP, it won't be available in post-auth.
If so, am I able to make a call to the dhcp_sqlippool to get an IP during the post-auth process or is there a better alternative method to do this?
You can call dhcp_sqlippool, but it won't do what you want. I think you're missing parts of the puzzle. For one, you're not explaining everything that's going on in your system. Is DHCP being assigned via RADIUS? What you *can* do is assign Framed-IP-Address in post-auth. Then, if you're using FreeRADIUS for DHCP, you can have it query the IP pool based on MAC to find the same IP. But that requires understanding how the pieces work together. There is no default configuration which just works here. Alan DeKok.
Thanks Alan Unfortunately the NAS does not include the Framed IP Address in its accounting packet which is what we require to enable automatic login to our content filter through wifi. I am pretty sure I am missing parts of the puzzle and am more than likely confusing myself. As our NAS does not include the framed IP address in its accounting packet, I was of the mindset to build a trial system that uses the FreeRadius server with the included DHCP and Radius authentication services. For the DHCP there are two VLAN subnets with the Radius authentication against a users file and returning the VLAN ID. This all works well as expected where the user authenticates successfully and the DHCP server returns an IP address from the correct IP Pool. I guess the missing puzzle piece for me is at which point does the client device obtain their IP address from the DHCP server, during post-auth or after post-auth? If it is after post-auth, then I am correct in saying that there would be no purpose in querying the FreeRadius DHCP IP pool database as the IP Address would not have been assigned by then? - Kind Regards - Byron Jeffery - On Wed, Aug 2, 2017 at 5:34 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Aug 1, 2017, at 8:21 AM, Byron Jeffery <byronjeffery@cem.org.au> wrote:
I currently have a test FreeRadius server setup for authentication (local user file) and DHCP which is working as intended, however, I am trying
to
implement a solution whereby the Framed IP Address attribute and username is sent to an accounting server at some point during or after the authentication process.
The NAS is responsible for sending accounting packets. If you want something in the accounting packets, see the NAS documentation.
My understanding is that after the user successfully authenticates, the client device then proceeds to obtain an IP address from the DHCP,
Yes. And the DHCP address assignment has pretty much nothing to do with RADIUS.
however, am I correct in saying that if I wish to obtain the Framed IP Address, I will not be able to obtain this after the authentication (ie: post-auth).
post-auth runs before the Access-Accept is sent back.
If the IP is assigned via DHCP, it won't be available in post-auth.
If so, am I able to make a call to the dhcp_sqlippool to get an IP during the post-auth process or is there a better alternative method to do this?
You can call dhcp_sqlippool, but it won't do what you want.
I think you're missing parts of the puzzle. For one, you're not explaining everything that's going on in your system. Is DHCP being assigned via RADIUS?
What you *can* do is assign Framed-IP-Address in post-auth. Then, if you're using FreeRADIUS for DHCP, you can have it query the IP pool based on MAC to find the same IP.
But that requires understanding how the pieces work together. There is no default configuration which just works here.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Wed, 2017-08-02 at 09:18 +1000, Byron Jeffery wrote:
I guess the missing puzzle piece for me is at which point does the client device obtain their IP address from the DHCP server, during post-auth or after post-auth? If it is after post-auth, then I am correct in saying that there would be no purpose in querying the FreeRadius DHCP IP pool database as the IP Address would not have been assigned by then?
Generally speaking the order is - Authentication happens first, to permit the device access to the network. Then the Accounting-Start as the new session is created. Then DHCP as the device tries to get an address. Finally you might get an Accounting Interim-Update with the new DHCP-assigned IP address for the session in it. So to do what you want to do you probably need to assign the IP address for the device in post-auth (at the end of authentication) keyed off the Calling-Station-ID, which is hopefully the device MAC address. You could send that back as Framed-IP-Address if you really want, but it sounds like the NAS won't care anyway. Then on Accounting-Start you can key off Calling-Station-ID to pull that IP address out of the database and create your own Framed-IP- Address, should you need it at this stage. Then in DHCP rather than assigning an IP address you should again just look it up in the database (again, Calling-Station-ID should be the MAC address) and send that back to the client. If there's nothing in the database then just refuse to send anything back, as the client hasn't been through authentication properly. And be careful around DHCP renewals and when IPs expire from the database for a particular device. As a start you should look at moving the IP address assignment from the DHCP authorize config into the RADIUS post-auth section, and then tweak from there. Or fix/replace the NAS so it correctly reports the device's IP address, which would probably be a lot simpler... -- Matthew
Thanks Matthew for confirming the process. I had managed to figure out exactly as you had mentioned whereby I would be getting the IP address during post-auth, thank you for the confirmation. I looked at the vlan id and then based on that set the pool and then called dhcp_sqlippool. I figured that this was the best way to get an IP address for the client based on the calling-station-id so that I could then have an IP address for accounting start. This also meant that the client would be served the same IP address based on its mac address once it had the access accept and hit up the DHCP server for an IP address. In my testing, this works well. When you mentioned accounting-start, I could not find any reference to it other than assume you are referring to the accounting section the the sites-enabled/default config. My other thought from research is to use the copy-acct-to-home-server, would that be correct, or am I wrong? Fixing the NAS relies on the vendor, which we have been advised that are working on it. However, I was of the mindset of building an interim solution until they release the fix. Thank you once again for you assistance. - Kind Regards - Byron Jeffery - On Wed, Aug 2, 2017 at 6:33 PM, Matthew Newton <mcn@freeradius.org> wrote:
On Wed, 2017-08-02 at 09:18 +1000, Byron Jeffery wrote:
I guess the missing puzzle piece for me is at which point does the client device obtain their IP address from the DHCP server, during post-auth or after post-auth? If it is after post-auth, then I am correct in saying that there would be no purpose in querying the FreeRadius DHCP IP pool database as the IP Address would not have been assigned by then?
Generally speaking the order is - Authentication happens first, to permit the device access to the network. Then the Accounting-Start as the new session is created. Then DHCP as the device tries to get an address. Finally you might get an Accounting Interim-Update with the new DHCP-assigned IP address for the session in it.
So to do what you want to do you probably need to assign the IP address for the device in post-auth (at the end of authentication) keyed off the Calling-Station-ID, which is hopefully the device MAC address. You could send that back as Framed-IP-Address if you really want, but it sounds like the NAS won't care anyway.
Then on Accounting-Start you can key off Calling-Station-ID to pull that IP address out of the database and create your own Framed-IP- Address, should you need it at this stage.
Then in DHCP rather than assigning an IP address you should again just look it up in the database (again, Calling-Station-ID should be the MAC address) and send that back to the client. If there's nothing in the database then just refuse to send anything back, as the client hasn't been through authentication properly. And be careful around DHCP renewals and when IPs expire from the database for a particular device.
As a start you should look at moving the IP address assignment from the DHCP authorize config into the RADIUS post-auth section, and then tweak from there.
Or fix/replace the NAS so it correctly reports the device's IP address, which would probably be a lot simpler...
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
Hi all I would like to thank you for all your assistance with my build of a Freeradius DHCP server using a SQL IPPOOL database. My test environment is running well and has been a perfect solution for including the Framed-IP-Address in the proxied accounting packet for our wifi infrastructure. I do have one question though regarding static IP addresses. I am a little confused on the best practice regarding setting up clients as to whether it is best to set them up in mac2ip file or entering them into a sql database. If I enter them into the sql database the lease period is set when the client successfully gets an IP address, however, how do I define a indefinite lease without it being overwritten? - Kind Regards - Byron Jeffery - ICT Helpdesk Coordinator ------------------------------ - Phone:0243636107 - Mobile:043 230 7030 - Fax:(07) 3889 7245 - Office:Suite 304, 200 The Central Coast Hwy, Erina NSW 2250 - Postal:PO Box 3101, Caboolture BC QLD 4510 ------------------------------ The content of this message is provided without responsibility in law for their accuracy or otherwise, and without assumption of a duty of care by Australian Christian College. Whilst every attempt has been made to ensure that material contained in this email is free from computer viruses or other defects, the attached files are provided, and may only be used, on the basis that the user assumes all responsibility for use of the material transmitted. This email is intended only for the use of the individual or entity names above and may contain information that is confidential and privileged. If you are not the intended recipient, please note that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email and destroy the original message. On Thu, Aug 3, 2017 at 9:08 PM, Byron Jeffery <byronjeffery@cem.org.au> wrote:
Thanks Matthew for confirming the process.
I had managed to figure out exactly as you had mentioned whereby I would be getting the IP address during post-auth, thank you for the confirmation.
I looked at the vlan id and then based on that set the pool and then called dhcp_sqlippool. I figured that this was the best way to get an IP address for the client based on the calling-station-id so that I could then have an IP address for accounting start. This also meant that the client would be served the same IP address based on its mac address once it had the access accept and hit up the DHCP server for an IP address. In my testing, this works well.
When you mentioned accounting-start, I could not find any reference to it other than assume you are referring to the accounting section the the sites-enabled/default config. My other thought from research is to use the copy-acct-to-home-server, would that be correct, or am I wrong?
Fixing the NAS relies on the vendor, which we have been advised that are working on it. However, I was of the mindset of building an interim solution until they release the fix.
Thank you once again for you assistance.
- Kind Regards
- Byron Jeffery -
On Wed, Aug 2, 2017 at 6:33 PM, Matthew Newton <mcn@freeradius.org> wrote:
On Wed, 2017-08-02 at 09:18 +1000, Byron Jeffery wrote:
I guess the missing puzzle piece for me is at which point does the client device obtain their IP address from the DHCP server, during post-auth or after post-auth? If it is after post-auth, then I am correct in saying that there would be no purpose in querying the FreeRadius DHCP IP pool database as the IP Address would not have been assigned by then?
Generally speaking the order is - Authentication happens first, to permit the device access to the network. Then the Accounting-Start as the new session is created. Then DHCP as the device tries to get an address. Finally you might get an Accounting Interim-Update with the new DHCP-assigned IP address for the session in it.
So to do what you want to do you probably need to assign the IP address for the device in post-auth (at the end of authentication) keyed off the Calling-Station-ID, which is hopefully the device MAC address. You could send that back as Framed-IP-Address if you really want, but it sounds like the NAS won't care anyway.
Then on Accounting-Start you can key off Calling-Station-ID to pull that IP address out of the database and create your own Framed-IP- Address, should you need it at this stage.
Then in DHCP rather than assigning an IP address you should again just look it up in the database (again, Calling-Station-ID should be the MAC address) and send that back to the client. If there's nothing in the database then just refuse to send anything back, as the client hasn't been through authentication properly. And be careful around DHCP renewals and when IPs expire from the database for a particular device.
As a start you should look at moving the IP address assignment from the DHCP authorize config into the RADIUS post-auth section, and then tweak from there.
Or fix/replace the NAS so it correctly reports the device's IP address, which would probably be a lot simpler...
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list /users.html
On Aug 28, 2017, at 5:27 AM, Byron Jeffery <byronjeffery@cem.org.au> wrote:
I do have one question though regarding static IP addresses. I am a little confused on the best practice regarding setting up clients as to whether it is best to set them up in mac2ip file or entering them into a sql database. If I enter them into the sql database the lease period is set when the client successfully gets an IP address, however, how do I define a indefinite lease without it being overwritten?
It's probably best to put static IPs into a separate table. Then, the logic looks like: if (get static IP) { we're OK } else { do sqlippool to assign dynamic IP } Mixing static IPs and dynamic IPs in the same table is problematic. Alan DeKok.
Hi Alan My apologies, I have realised that I had my terminology mixed up. I was meaning to say static DHCP lease IP rather than the static IP address itself. I am also looking forwards to V4 as I have read that there are plans for the DHCP service. Are there any particular planned changes for the DHCP service? - Kind Regards - Byron Jeffery - ICT Helpdesk Coordinator ------------------------------ - Phone:0243636107 - Mobile:043 230 7030 - Office:Suite 304, 200 The Central Coast Hwy, Erina NSW 2250 ------------------------------ The content of this message is provided without responsibility in law for their accuracy or otherwise, and without assumption of a duty of care by Australian Christian College. Whilst every attempt has been made to ensure that material contained in this email is free from computer viruses or other defects, the attached files are provided, and may only be used, on the basis that the user assumes all responsibility for use of the material transmitted. This email is intended only for the use of the individual or entity names above and may contain information that is confidential and privileged. If you are not the intended recipient, please note that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email and destroy the original message. On Mon, Aug 28, 2017 at 9:45 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Aug 28, 2017, at 5:27 AM, Byron Jeffery <byronjeffery@cem.org.au> wrote:
I do have one question though regarding static IP addresses. I am a little confused on the best practice regarding setting up clients as to whether it is best to set them up in mac2ip file or entering them into a sql database. If I enter them into the sql database the lease period is set when the client successfully gets an IP address, however, how do I define a indefinite lease without it being overwritten?
It's probably best to put static IPs into a separate table. Then, the logic looks like:
if (get static IP) { we're OK } else { do sqlippool to assign dynamic IP }
Mixing static IPs and dynamic IPs in the same table is problematic.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Aug 31, 2017, at 11:29 PM, Byron Jeffery <byronjeffery@cem.org.au> wrote:
My apologies, I have realised that I had my terminology mixed up. I was meaning to say static DHCP lease IP rather than the static IP address itself.
The sql IP pool module assigns leases which are in the IP pool. If you want a lease to NOT be allocated dynamically, remove it from the pool, and assign it statically. That's how static IP allocations work.
I am also looking forwards to V4 as I have read that there are plans for the DHCP service. Are there any particular planned changes for the DHCP service?
It will still act as DHCP. The major change will be the ability to receive an Access-Request, and forward an Accounting-Request, or DHCP packet. Alan DeKok.
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
Byron Jeffery -
Matthew Newton -
Matthew Newton