dhcp sqlippool reauthenticate users every minute
Hi, I'm trying to set up FreeRADIUS 2.2 to act as an authentication and accounting system as well as a DHCP server. (I'm relaying DHCP requests from a pfSense box). I am trying to use sqlippools on FreeRADIUS, but I have noticed that my ippools are filling up quickly (I am only testing with two devices). I have pfSense configured to reauthenticate user every minute, so I believe that FreeRADIUS is running post-auth dhcp leasing each time the user is reauthenticated. FreeRADIUS is serving the same client a new IP address each minute. I have adjusted my policy conf to the below. I may be approaching this the wrong way, but this is essentially what I am trying to do: I want to have multiple pools on different subnets. When a new client connects to the network (they don't yet have a radius account) they are sent to a default (pending) pool. This may be on the 192.168.1/24 subnet. After they have set up their account and have been added to the RADIUS database, they will be given a pool-name, maybe `pool2`. `pool2` will be on a different subnet, for example, 192168.2/24. The pfsense box knows how to route these subnets, so that is not a problem. I only want clients to receive a different IP address if their pool-name changes for whatever reason, if there are no changes to their account, they shouldn't be leased a new IP every time they reauthenticate (every minute). Eventually I will disable the reauthenticate every minute feature as the production system would not be able to handle this many requests. Am I approaching this problem correctly? I have written some un-lang in the policy.conf file for handling some of this. I am getting hung up on this problem. The pool is getting exhausted in minutes since each client is leased a new ip every minute. Any help is appreciated! Thanks, Ethan …. dhcp_sqlippool.post-auth { # Do some minor hacks to the request so that it looks # like a RADIUS request to the SQL IP Pool module. # check whether the requester is a user or not, if they do not have a pool-name, send them to pfpriv by default if("%{sql: SELECT COUNT(*) FROM radcheck where username='%{DHCP-Client-Hardware-Address}' AND attribute='Pool-Name'}" != "0") { update control { Pool-Name := "%{sql: SELECT `value` FROM radcheck WHERE username = '%{DHCP-Client-Hardware-Address}' AND attribute='Pool-Name'}" } } else { update control { Pool-Name := "pfpriv" # default pool if the user doesn't have an account } } update reply { DHCP-Domain-Name-Server = "192.168.1.1" # we will ultimately create a mysql table `radpoolinfo` to store per-pool attributes DHCP-Router-Address = "192.168.0.1" # this will also be in `radpoolinfo` eventually } update request { User-Name = "DHCP-%{DHCP-Client-Hardware-Address}" Calling-Station-Id = "%{DHCP-Client-Hardware-Address}" NAS-IP-Address = "%{%{DHCP-Gateway-IP-Address}:-127.0.0.1}" Acct-Status-Type = Start } # Call the actual module # # Uncomment this in order to really call it! dhcp_sqlippool #fail # Convert Framed-IP-Address to DHCP, but only if we # actually allocated an address. if (ok) { update reply { DHCP-Your-IP-Address = "%{reply:Framed-IP-Address}" } } } …
Ethan Hayon wrote:
Hi, I'm trying to set up FreeRADIUS 2.2 to act as an authentication and accounting system as well as a DHCP server. (I'm relaying DHCP requests from a pfSense box).
Are you doing DHCP *and* RADIUS?
I am trying to use sqlippools on FreeRADIUS, but I have noticed that my ippools are filling up quickly (I am only testing with two devices). I have pfSense configured to reauthenticate user every minute, so I believe that FreeRADIUS is running post-auth dhcp leasing each time the user is reauthenticated. FreeRADIUS is serving the same client a new IP address each minute.
There's no need to "believe" anything. Run the server in debugging mode to see exactly what it's doing. Any IP allocation MUST be done on a key which is unique to each device. That key should remain the same across multiple re-authentications. So... is it? Please check.
I want to have multiple pools on different subnets. When a new client connects to the network (they don't yet have a radius account) they are sent to a default (pending) pool. This may be on the 192.168.1/24 subnet. After they have set up their account and have been added to the RADIUS database, they will be given a pool-name, maybe `pool2`. `pool2` will be on a different subnet, for example, 192168.2/24. The pfsense box knows how to route these subnets, so that is not a problem. I only want clients to receive a different IP address if their pool-name changes for whatever reason, if there are no changes to their account, they shouldn't be leased a new IP every time they reauthenticate (every minute).
This is what databases are for. If you want to map each client to a pool, you'll need a table with a "client identifier" column, and a "pool-name" column. Then, assign IPs based on the pool name, as looked up in the table.
Am I approaching this problem correctly? I have written some un-lang in the policy.conf file for handling some of this. I am getting hung up on this problem. The pool is getting exhausted in minutes since each client is leased a new ip every minute.
Solve that problem first. Run the server in debugging mode to see *why* it's assigning a new IP. Alan DeKok.
Thanks for the response Alan. I am using DHCP and RADIUS. I was initially using FreeRADIUS for captive portal user authentication and accounting for a pfsense router (using the DHCP server built into the pfsense box). The DHCP server on pfsense limits us to only serving IPs on a singe subnet. We are now trying to use FreeRADIUS as a DHCP server as well by associating user accounts with ippools through Pool-Name. When I run the server in debug mode the Acct-Unique-Session-ID remains the same across the interim accounting updates. However, re-authentications don't seem to have a unique key associated with them. Each time the user is reauthenticated, dhcp_sqlippool.post-auth is triggered and the script I added is executed. I plan to create a table radippoolinfo that will store ip pool specific info such as router address, net mask, dns servers, etc… In my post-auth policy, I am updating control with the proper pool-name (with an unlang), changing some other reply attributes, then calling dhcp_sqlippool. What I am doing doesn't feel right. I am very new to this, does this sound like the proper way of handling the serving of ip's on multiple subnets. DHCP-Domain-Name-Server and DHCP-Router-Address will change between pools. I guess I'm asking if I am approaching this correctly: Using unlang in policy.conf to handle these rules. Sorry to put such a long debug message in here. I pulled out one authorization request, but they all look the same. It looks like This is what my authorization looks like: The request comes in with a framed ip of 192.168.0.43, but it tries to serve it 192.168.0.50. It reallocates a new IP for each auth every minute. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- rad_recv: Access-Request packet from host 192.168.1.1 port 7053, id=32, length=142 NAS-IP-Address = [redacted] NAS-Identifier = "pfsense.localdomain" User-Name = "b8:8d:12:10:8d:f6" User-Password = "[redacted]" Service-Type = Login-User NAS-Port-Type = Ethernet NAS-Port = 30 Framed-IP-Address = 192.168.0.43 Called-Station-Id = "[redacted]" Calling-Station-Id = "b8:8d:12:10:8d:f6" Thu Jan 10 23:53:34 2013 : Info: # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default Thu Jan 10 23:53:34 2013 : Info: +- entering group authorize {...} Thu Jan 10 23:53:34 2013 : Info: ++[preprocess] returns ok Thu Jan 10 23:53:34 2013 : Info: ++[chap] returns noop Thu Jan 10 23:53:34 2013 : Info: ++[mschap] returns noop Thu Jan 10 23:53:34 2013 : Info: ++[digest] returns noop Thu Jan 10 23:53:34 2013 : Info: [suffix] No '@' in User-Name = "b8:8d:12:10:8d:f6", looking up realm NULL Thu Jan 10 23:53:34 2013 : Info: [suffix] No such realm "NULL" Thu Jan 10 23:53:34 2013 : Info: ++[suffix] returns noop Thu Jan 10 23:53:34 2013 : Info: [eap] No EAP-Message, not doing EAP Thu Jan 10 23:53:34 2013 : Info: ++[eap] returns noop Thu Jan 10 23:53:34 2013 : Info: [files] users: Matched entry DEFAULT at line 93 Thu Jan 10 23:53:34 2013 : Info: ++[files] returns ok Thu Jan 10 23:53:34 2013 : Info: [sql] expand: %{User-Name} -> b8:8d:12:10:8d:f6 Thu Jan 10 23:53:34 2013 : Info: [sql] sql_set_user escaped user --> 'b8:8d:12:10:8d:f6' Thu Jan 10 23:53:34 2013 : Debug: rlm_sql (sql): Reserving sql socket id: 0 Thu Jan 10 23:53:34 2013 : Info: [sql] expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'b8:8d:12:10:8d:f6' ORDER BY id Thu Jan 10 23:53:34 2013 : Info: [sql] User found in radcheck table Thu Jan 10 23:53:34 2013 : Info: [sql] expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'b8:8d:12:10:8d:f6' ORDER BY id Thu Jan 10 23:53:34 2013 : Info: [sql] expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'b8:8d:12:10:8d:f6' ORDER BY priority Thu Jan 10 23:53:34 2013 : Debug: rlm_sql (sql): Released sql socket id: 0 Thu Jan 10 23:53:34 2013 : Info: ++[sql] returns ok Thu Jan 10 23:53:34 2013 : Info: ++[expiration] returns noop Thu Jan 10 23:53:34 2013 : Info: ++[logintime] returns noop Thu Jan 10 23:53:34 2013 : Info: [pap] WARNING: Auth-Type already set. Not setting to PAP Thu Jan 10 23:53:34 2013 : Info: ++[pap] returns noop Thu Jan 10 23:53:34 2013 : Info: Found Auth-Type = Accept Thu Jan 10 23:53:34 2013 : Info: Auth-Type = Accept, accepting the user Thu Jan 10 23:53:34 2013 : Info: # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default Thu Jan 10 23:53:34 2013 : Info: +- entering group post-auth {...} Thu Jan 10 23:53:34 2013 : Info: [sql] expand: %{User-Name} -> b8:8d:12:10:8d:f6 Thu Jan 10 23:53:34 2013 : Info: [sql] sql_set_user escaped user --> 'b8:8d:12:10:8d:f6' Thu Jan 10 23:53:34 2013 : Info: [sql] expand: %{User-Password} -> [redacted] Thu Jan 10 23:53:34 2013 : Info: [sql] expand: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '%{User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S') -> INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'b8:8d:12:10:8d:f6', '[redacted]', 'Access-Accept', '2013-01-10 23:53:34') Thu Jan 10 23:53:34 2013 : Debug: rlm_sql (sql) in sql_postauth: query is INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( 'b8:8d:12:10:8d:f6', '[redacted]', 'Access-Accept', '2013-01-10 23:53:34') Thu Jan 10 23:53:34 2013 : Debug: rlm_sql (sql): Reserving sql socket id: 4 Thu Jan 10 23:53:34 2013 : Debug: rlm_sql (sql): Released sql socket id: 4 Thu Jan 10 23:53:34 2013 : Info: ++[sql] returns ok Thu Jan 10 23:53:34 2013 : Debug: rlm_sql (sql): Reserving sql socket id: 3 Thu Jan 10 23:53:34 2013 : Info: [sqlippool] expand: %{User-Name} -> b8:8d:12:10:8d:f6 Thu Jan 10 23:53:34 2013 : Info: [sqlippool] sql_set_user escaped user --> 'b8:8d:12:10:8d:f6' Thu Jan 10 23:53:34 2013 : Info: [sqlippool] expand: START TRANSACTION -> START TRANSACTION Thu Jan 10 23:53:34 2013 : Info: [sqlippool] expand: UPDATE radippool SET nasipaddress = '', pool_key = 0, callingstationid = '', username = '', expiry_time = NULL WHERE expiry_time <= NOW() - INTERVAL 1 SECOND AND nasipaddress = '%{Nas-IP-Address}' -> UPDATE radippool SET nasipaddress = '', pool_key = 0, callingstationid = '', username = '', expiry_time = NULL WHERE expiry_time <= NOW() - INTERVAL 1 SECOND AND nasipaddress = '[redacted]' Thu Jan 10 23:53:34 2013 : Info: [sqlippool] expand: SELECT framedipaddress FROM radippool WHERE pool_name = '%{control:Pool-Name}' AND (expiry_time < NOW() OR expiry_time IS NULL) ORDER BY (username <> '%{User-Name}'), (callingstationid <> '%{Calling-Station-Id}'), expiry_time LIMIT 1 FOR UPDATE -> SELECT framedipaddress FROM radippool WHERE pool_name = 'pfpriv' AND (expiry_time < NOW() OR expiry_time IS NULL) ORDER BY (username <> 'b8:8d:12:10:8d:f6'), (callingstationid <> 'b8:8d:12:10:8d:f6'), expiry_time LIMIT 1 FOR UPDATE Thu Jan 10 23:53:34 2013 : Info: [sqlippool] expand: UPDATE radippool SET nasipaddress = '%{NAS-IP-Address}', pool_key = '%{Calling-Station-Id}', callingstationid = '%{Calling-Station-Id}', username = '%{User-Name}', expiry_time = NOW() + INTERVAL 3600 SECOND WHERE framedipaddress = '192.168.0.50' AND expiry_time IS NULL -> UPDATE radippool SET nasipaddress = '[redacted]', pool_key = 'b8:8d:12:10:8d:f6', callingstationid = 'b8:8d:12:10:8d:f6', username = 'b8:8d:12:10:8d:f6', expiry_time = NOW() + INTERVAL 3600 SECOND WHERE framedipaddress = '192.168.0.50' AND expiry_time IS NULL Thu Jan 10 23:53:34 2013 : Info: [sqlippool] Allocated IP 192.168.0.50 [3200a8c0] Thu Jan 10 23:53:34 2013 : Info: [sqlippool] expand: COMMIT -> COMMIT Thu Jan 10 23:53:34 2013 : Debug: rlm_sql (sql): Released sql socket id: 3 Thu Jan 10 23:53:34 2013 : Info: [sqlippool] expand: Allocated IP: %{reply:Framed-IP-Address} from %{control:Pool-Name} (did %{Called-Station-Id} cli %{Calling-Station-Id} port %{NAS-Port} user %{User-Name}) -> Allocated IP: 192.168.0.50 from pfpriv (did [redacted] cli b8:8d:12:10:8d:f6 port 30 user b8:8d:12:10:8d:f6) Thu Jan 10 23:53:34 2013 : Info: Allocated IP: 192.168.0.50 from pfpriv (did [redacted] cli b8:8d:12:10:8d:f6 port 30 user b8:8d:12:10:8d:f6) Thu Jan 10 23:53:34 2013 : Info: ++[sqlippool] returns ok Thu Jan 10 23:53:34 2013 : Info: ++[exec] returns noop Sending Access-Accept of id 32 to 192.168.1.1 port 7053 WISPr-Bandwidth-Max-Up := 5000000 WISPr-Bandwidth-Max-Down := 12000000 Framed-IP-Address = 192.168.0.50 Thu Jan 10 23:53:34 2013 : Info: Finished request 10. Thu Jan 10 23:53:34 2013 : Debug: Going to the next request Thu Jan 10 23:53:34 2013 : Debug: Waking up in 4.9 seconds. Thu Jan 10 23:53:39 2013 : Info: Cleaning up request 10 ID 32 with timestamp +268 Thu Jan 10 23:53:39 2013 : Info: Ready to process requests. On Jan 11, 2013, at 4:34 PM, Alan DeKok <aland@deployingradius.com> wrote:
Ethan Hayon wrote:
Hi, I'm trying to set up FreeRADIUS 2.2 to act as an authentication and accounting system as well as a DHCP server. (I'm relaying DHCP requests from a pfSense box).
Are you doing DHCP *and* RADIUS?
I am trying to use sqlippools on FreeRADIUS, but I have noticed that my ippools are filling up quickly (I am only testing with two devices). I have pfSense configured to reauthenticate user every minute, so I believe that FreeRADIUS is running post-auth dhcp leasing each time the user is reauthenticated. FreeRADIUS is serving the same client a new IP address each minute.
There's no need to "believe" anything. Run the server in debugging mode to see exactly what it's doing.
Any IP allocation MUST be done on a key which is unique to each device. That key should remain the same across multiple re-authentications.
So... is it? Please check.
I want to have multiple pools on different subnets. When a new client connects to the network (they don't yet have a radius account) they are sent to a default (pending) pool. This may be on the 192.168.1/24 subnet. After they have set up their account and have been added to the RADIUS database, they will be given a pool-name, maybe `pool2`. `pool2` will be on a different subnet, for example, 192168.2/24. The pfsense box knows how to route these subnets, so that is not a problem. I only want clients to receive a different IP address if their pool-name changes for whatever reason, if there are no changes to their account, they shouldn't be leased a new IP every time they reauthenticate (every minute).
This is what databases are for. If you want to map each client to a pool, you'll need a table with a "client identifier" column, and a "pool-name" column. Then, assign IPs based on the pool name, as looked up in the table.
Am I approaching this problem correctly? I have written some un-lang in the policy.conf file for handling some of this. I am getting hung up on this problem. The pool is getting exhausted in minutes since each client is leased a new ip every minute.
Solve that problem first. Run the server in debugging mode to see *why* it's assigning a new IP.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ethan Hayon wrote:
When I run the server in debug mode the Acct-Unique-Session-ID remains the same across the interim accounting updates. However, re-authentications don't seem to have a unique key associated with them.
That makes no sense. There is *nothing* unique to each user you can key off of? Name? MAC address?
In my post-auth policy, I am updating control with the proper pool-name (with an unlang), changing some other reply attributes, then calling dhcp_sqlippool. What I am doing doesn't /feel/ right. I am very new to this, does this sound like the proper way of handling the serving of ip's on multiple subnets. DHCP-Domain-Name-Server and DHCP-Router-Address will change between pools.
Get one thing working first. Only then look at the next thing.
I guess I'm asking if I am approaching this correctly: Using unlang in policy.conf to handle these rules.
unlang is for policy rules. Databases are for data. You've got some kind of mixup between the two.
Sorry to put such a long debug message in here. I pulled out one authorization request, but they all look the same. It looks like
They don't all look the same. They contain different information for each user. How else does the server tell users apart?
This is what my authorization looks like:
The request comes in with a framed ip of 192.168.0.43, but it tries to serve it 192.168.0.50.
The default queries use Calling-Station-Id to track IP addresses. They *also* assume that the NAS sends accounting packets, so that each user has an accounting entry in SQL.
It reallocates a new IP for each auth every minute.
Probably because the NAS isn't sending accounting data. So the IP is never tracked in SQL. So... did you look in the SQL database to see what's there? Is it tracking the IP? Does the user have an accounting record? Alan DeKok.
On Jan 11, 2013, at 6:38 PM, Alan DeKok <aland@deployingradius.com> wrote: Hi Alan, Thanks for the response
Ethan Hayon wrote:
When I run the server in debug mode the Acct-Unique-Session-ID remains the same across the interim accounting updates. However, re-authentications don't seem to have a unique key associated with them.
That makes no sense. There is *nothing* unique to each user you can key off of? Name? MAC address?
Yes, MAC address is unique for each user. The MAC should be a unique identifier when assigning IP's.
In my post-auth policy, I am updating control with the proper pool-name (with an unlang), changing some other reply attributes, then calling dhcp_sqlippool. What I am doing doesn't /feel/ right. I am very new to this, does this sound like the proper way of handling the serving of ip's on multiple subnets. DHCP-Domain-Name-Server and DHCP-Router-Address will change between pools.
Get one thing working first. Only then look at the next thing.
Good point
I guess I'm asking if I am approaching this correctly: Using unlang in policy.conf to handle these rules.
unlang is for policy rules. Databases are for data. You've got some kind of mixup between the two.
Sorry for the misunderstanding. I understand this. I'm just making sure it is normal to use unlang in the policy.conf to perform sql queries and use the results to build up a response. Again, I need to get this working before worrying about that.
Sorry to put such a long debug message in here. I pulled out one authorization request, but they all look the same. It looks like
They don't all look the same. They contain different information for each user. How else does the server tell users apart?
I am only using one device right now, so the auth requests look the same, hence why I only included one below. The auth requests will look different if i introduce more devices into the system.
This is what my authorization looks like:
The request comes in with a framed ip of 192.168.0.43, but it tries to serve it 192.168.0.50.
The default queries use Calling-Station-Id to track IP addresses. They *also* assume that the NAS sends accounting packets, so that each user has an accounting entry in SQL.
It reallocates a new IP for each auth every minute.
Probably because the NAS isn't sending accounting data. So the IP is never tracked in SQL.
So... did you look in the SQL database to see what's there? Is it tracking the IP? Does the user have an accounting record?
Yes, the NAS is sending accounting data. This is what redacct looks like (some columns omitted) +-----------+------------------+------------------+-------------------+---------------+-------------------+-----------------+-----------------+ | radacctid | acctsessionid | acctuniqueid | username | nasipaddress | callingstationid | calledstationid | framedipaddress | +-----------+------------------+------------------+-------------------+---------------+-------------------+-----------------+-----------------+ | 17 | 9e90e1a3b02da713 | 068649e121f096f2 | b8:8d:12:10:8d:f6 | 98.109.201.89 | b8:8d:12:10:8d:f6 | 98.109.201.89 | 192.168.0.40 | | 18 | 61ebc2f61333e8d4 | 857f2f856c1ea384 | b8:8d:12:10:8d:f6 | 98.109.201.89 | b8:8d:12:10:8d:f6 | 98.109.201.89 | 192.168.0.43 | | 19 | a8aed7c0d9ce3bd1 | 541ef5a9672cc6e7 | b8:8d:12:10:8d:f6 | 98.109.201.89 | b8:8d:12:10:8d:f6 | 98.109.201.89 | 192.168.0.43 | | 20 | 5bd18f3ccb1edf8a | e3c55f048d9a680b | b8:8d:12:10:8d:f6 | 98.109.201.89 | b8:8d:12:10:8d:f6 | 98.109.201.89 | 192.168.0.43 | | 21 | 72ad87c6b43a08b4 | e427b47f54737c4f | b8:8d:12:10:8d:f6 | 98.109.201.89 | b8:8d:12:10:8d:f6 | 98.109.201.89 | 192.168.0.43 | | 22 | bff889e83c3b469b | 70ec2fe5fa197bcc | b8:8d:12:10:8d:f6 | 98.109.201.89 | b8:8d:12:10:8d:f6 | 98.109.201.89 | 192.168.0.43 | +-----------+------------------+------------------+-------------------+---------------+-------------------+-----------------+-----------------+ So there is an accounting record for each user and each user session. Right now, I'm thinking there is a mismatch either in the nasipaddress or some other attribute. The NAS has a WAN ip of 98.109.201.89 and a LAN IP of 192.168.1.1. The RADIUS server is on LAN at 192.168.1.2. I have noticed that sometimes the nasipaddress appears as 192.168.1.1 and other times as 98.109.201.89. I think I am going to start with a fresh install of freeradius. I messed with too many queries (such as adjusting the Pool-Key) and I am worried that I have created a mess. Ethan Hayon
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ethan Hayon wrote:
Yes, MAC address is unique for each user. The MAC should be a unique identifier when assigning IP's.
That's the goal.
Yes, the NAS is sending accounting data. This is what redacct looks like (some columns omitted)
That seems OK.
Right now, I'm thinking there is a mismatch either in the nasipaddress or some other attribute. The NAS has a WAN ip of 98.109.201.89 and a LAN IP of 192.168.1.1. The RADIUS server is on LAN at 192.168.1.2. I have noticed that sometimes the nasipaddress appears as 192.168.1.1 and other times as 98.109.201.89. I think I am going to start with a fresh install of freeradius. I messed with too many queries (such as adjusting the Pool-Key) and I am worried that I have created a mess.
Well, start over. See "man radiusd". Change one thing at a time. Get it working. Once it's working, change something else. Alan DeKok.
participants (2)
-
Alan DeKok -
Ethan Hayon