Release of the IP after the Acct-Stop (ippool)

[Alan DeKok]

On Oct 29, 2018, at 12:26 PM, Lars Hillebrand <lars.hillebrand at fh-dortmund.de> wrote:
> In the site-availiable configuration for vpn we have configured several ippools (see below).
> Each entry with the defined IP ranges for the corresponding department of our university.
> For example FB1-B (employees Department 1) or FB1-S (students Department 1)

  That's a lot clearer.

> The assignment of the correct Ippool based on group memberships works.
> Only the release of the IP address after the termination of the connection does not work.
> 
> In the following debug log, the person is assigned an IP address from the DVZ-S area when connecting. However, when the connection is stopped, the IP address is not released again because only the first entry (FB1-B) is checked. After the ippool FB1-B, the next ippool FB1-S is not checked.
> I hope I was able to explain our mistake better. 
> 
> (2116) Mon Oct 29 15:15:52 2018: Debug: Received Access-Request Id 39 from 193.25.18.219:48008 to 10.100.16.162:2001 length 184

  Again, PLEASE READ THE DOCUMENTATION FOR WHAT TO POST TO THE LIST.

  We don't need "radiusd -Xx", or "radiusd -Xxxxxxxxx" or anything else.  We need "radiusd -X".  The extra information is useless and annoying.  All it does is show us that you're not following the documentation.

> (2116) Mon Oct 29 15:15:52 2018: Debug: files_vpn: Searching for user in group "FB1"
> (2116) Mon Oct 29 15:15:52 2018: Debug: files_vpn: Using user DN from request "cn=user1,ou=users,o=fhdo"
> (2116) Mon Oct 29 15:15:52 2018: Debug: files_vpn: Checking for user in group objects
> (2116) Mon Oct 29 15:15:52 2018: Debug: files_vpn:   EXPAND (&(cn=FB1)(objectClass=groupOfNames)(member=%{control:Ldap-UserDn}))
> (2116) Mon Oct 29 15:15:52 2018: Debug: files_vpn:      --> (&(cn=FB1)(objectClass=groupOfNames)(member=cn\3duser1\2cou\3dusers\2co\3dfhdo))
> (2116) Mon Oct 29 15:15:52 2018: Debug: files_vpn:   Performing search in "o=FHDO" with filter "(&(cn=FB1)(objectClass=groupOfNames)(member=cn\3duser1\2cou\3dusers\2co\3dfhdo))", scope "sub"
> (2116) Mon Oct 29 15:15:52 2018: Debug: files_vpn:   Waiting for search result...
> (2116) Mon Oct 29 15:15:52 2018: Debug: files_vpn:   Search returned no results

  And tons and tons of similar output.  That's not necessary.

  You can do LDAP group checks in the "authorize" section.  And in v3, they will be cached.  So it won't do 30 LDAP lookups on every packet.

> (2116) Mon Oct 29 15:15:52 2018: Debug: # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/vpn
> (2116) Mon Oct 29 15:15:52 2018: Debug:   post-auth {
> (2116) Mon Oct 29 15:15:52 2018: Debug:     update {
> (2116) Mon Oct 29 15:15:52 2018: Debug:       No attributes updated
> (2116) Mon Oct 29 15:15:52 2018: Debug:     } # update = noop
> (2116) Mon Oct 29 15:15:52 2018: Debug:     [FB1-B] = noop
> (2116) Mon Oct 29 15:15:52 2018: Debug:     [FB1-S] = noop

  That's also inefficient.  Why are you doing dozens of LDAP group checks and then *ignoring* all of that information, and doing dozens of checks for IP allocation?

  It's much simpler (and faster and better) to do the *right thing*:

	if user is in LDAP group foo
		assign IP from pool foo

> (2153) Mon Oct 29 15:15:53 2018: Debug: Received Accounting-Request Id 40 from 193.25.18.219:38622 to 10.100.16.162:2011 length 177
> (2153) Mon Oct 29 15:15:53 2018: Debug:   User-Name = "user1"
> (2153) Mon Oct 29 15:15:53 2018: Debug:   NAS-Port = 202297344

  OK...
> ..
> (2153) Mon Oct 29 15:15:53 2018: Debug: FB1-B: This is not an Accounting-Stop
> (2153) Mon Oct 29 15:15:53 2018: Debug:     [FB1-B] = noop
> (2153) Mon Oct 29 15:15:53 2018: Debug: FB1-S: This is not an Accounting-Stop
> (2153) Mon Oct 29 15:15:53 2018: Debug:     [FB1-S] = noop

  The same comments apply here.  Why did dozens of useless checks?

> Here the configuration site-available/vpn 

  We don't need the configuration files.  The documentation I told you to read says DO NOT POST CONFIGURATION FILES.

  If you want us to help you, then it makes sense to read the documentation and follow it.

  And to answer your question, you can fix the problem by creating a *good* configuration.  Do the LDAP group checks, and pick the right IP pool.

  If you want to know how to control fail-over when a module returns "noop", then read the documentation.  A good guide is here:  https://networkradius.com/doc/FreeRADIUS-Technical-Guide.pdf

  Alan DeKok.