Tunnel-Password length not multiple of 16
Hi, I've been trying to migrate from FreeRADIUS ver 1.1.3 to ver 3.0.4. I've setup new servers running MariaDB and FreeRADIUS 3.0.4 and have left the ver 3 config as default as possible with just changing a few things like the listen port and the SQL database parameters, and of course clients.conf and huntgroup. All looks good at first glance and the radtest utility works and returns what is expected and the debug shows Access-Accept. But when I run a "test aaa group" from the Cisco router it returns a "User rejected" and the "debug radius" outputs the following. router#test aaa group vpn-dialin-auth-test user-name cisco new-code User rejected router# Apr 18 16:01:39 SAST: RADIUS/ENCODE(00000000):Orig. component type = Invalid Apr 18 16:01:39 SAST: RADIUS/ENCODE(00000000): dropping service type, "radius-server attribute 6 on-for-login-auth" is off Apr 18 16:01:39 SAST: RADIUS(00000000): Config NAS IP: 172.16.0.1 Apr 18 16:01:39 SAST: RADIUS(00000000): Config NAS IPv6: :: Apr 18 16:01:39 SAST: RADIUS(00000000): sending Apr 18 16:01:39 SAST: RADIUS/DECODE(00000000): There is no General DB. Want server details may not be specified Apr 18 16:01:39 SAST: RADIUS(00000000): Send Access-Request to 172.16.0.2:18122 id 1645/8, len 57 Apr 18 16:01:39 SAST: RADIUS: authenticator DC F4 D6 39 DF 63 68 B4 - 16 06 B4 62 A3 44 9F 06 Apr 18 16:01:39 SAST: RADIUS: User-Password [2] 18 * Apr 18 16:01:39 SAST: RADIUS: User-Name [1] 13 "user-name" Apr 18 16:01:39 SAST: RADIUS: NAS-IP-Address [4] 6 172.16.0.1 Apr 18 16:01:39 SAST: RADIUS(00000000): Sending a IPv4 Radius Packet Apr 18 16:01:39 SAST: RADIUS(00000000): Started 5 sec timeout Apr 18 16:01:39 SAST: RADIUS: Received from id 1645/8 172.16.0.2:18122, Access-Accept, len 154 Apr 18 16:01:39 SAST: RADIUS: authenticator 02 9B 45 F7 98 F7 3F AB - 98 54 71 59 F3 73 29 76 Apr 18 16:01:39 SAST: RADIUS: Service-Type [6] 6 Outbound [5] Apr 18 16:01:39 SAST: RADIUS: Tunnel-Type [64] 6 00:ESP [9] Apr 18 16:01:39 SAST: RADIUS: Tunnel-Password [69] 52 00:* Apr 18 16:01:39 SAST: RADIUS: Vendor, Cisco [26] 30 Apr 18 16:01:39 SAST: RADIUS: Cisco AVpair [1] 24 "ipsec:key-exchange=ike" Apr 18 16:01:39 SAST: RADIUS: Vendor, Cisco [26] 40 Apr 18 16:01:39 SAST: RADIUS: Cisco AVpair [1] 34 "ipsec:key-exchange=preshared-key" Apr 18 16:01:39 SAST: RADIUS/DECODE(00000000): There is no General DB. Reply server details may not be recorded router# Apr 18 16:01:39 SAST: RADIUS(00000000): Received from id 1645/8 Apr 18 16:01:39 SAST: RADIUS: Tunnel-Password length not multiple of 16 Apr 18 16:01:39 SAST: RADIUS/DECODE: decoder; FAIL Apr 18 16:01:39 SAST: RADIUS/DECODE: attribute Tunnel-Password; FAIL Apr 18 16:01:39 SAST: RADIUS/DECODE: parse response op decode; FAIL You can see the Cisco router has received an "Access-Accept" from the line "RADIUS: Received from id 1645/8 172.16.0.2:18122, Access-Accept, len 154" but the debug returns that last bit about the Tunnel-Password. If I run the same test against the current live aaa group, which wuthenticates against the ver 1.1.3 FreeRADIUS, it all works fine as it should being the live setup. router#test aaa group vpn-dialin-auth user-name cisco new-code User successfully authenticated USER ATTRIBUTES service-type 0 5 [Outbound] tunnel-type 0 9 [esp] tunnel-password 0 <hidden> key-exchange 0 "ike" key-exchange 0 "preshared-key" The aaa groups are identical except the radius server defined to authenticate against and all the other bits that Cisco references are setup for the test group too. I have done the changes in the database for ver 3 like this one - changing attribute from "Password" to "Cleartext-Password" and the op to be ":=" +----+-------------+--------------------+----+-------+ | id | UserName | Attribute | op | Value | +----+-------------+--------------------+----+-------+ | 33 | user-name | Cleartext-Password | := | cisco | +----+-------------+--------------------+----+-------+ As far as the RADIUS debug is concerned all was good and successful, but clearly Cisco thinks otherwise... Please could someone point me in the correct direct as I've spent a few days now searching for this "error" to no avail... Rhys McWilliams ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
On Apr 18, 2016, at 10:22 AM, McWilliams, Rhys <rhys.mcwilliams@cdk.com> wrote:
I've been trying to migrate from FreeRADIUS ver 1.1.3 to ver 3.0.4.
Please use 3.0.11. 3.0.4 is years old.
I've setup new servers running MariaDB and FreeRADIUS 3.0.4 and have left the ver 3 config as default as possible with just changing a few things like the listen port and the SQL database parameters, and of course clients.conf and huntgroup.
That should be all good.
All looks good at first glance and the radtest utility works and returns what is expected and the debug shows Access-Accept. But when I run a "test aaa group" from the Cisco router it returns a "User rejected" and the "debug radius" outputs the following.
And.... what does the debug output of the *server* say? If you do "radiusd -Xxx", you will get hex dumps of the packets it sends and receives.
You can see the Cisco router has received an "Access-Accept" from the line "RADIUS: Received from id 1645/8 172.16.0.2:18122, Access-Accept, len 154" but the debug returns that last bit about the Tunnel-Password.
It should be able to handle such attributes. But also the server should create well-formed attributes.
Please could someone point me in the correct direct as I've spent a few days now searching for this "error" to no avail...
Try 3.0.11. It has a number of issues fixed over 3.0.4. Alan DeKok.
Hi Alan, Thanks for the quick reply...
Try 3.0.11. It has a number of issues fixed over 3.0.4. We run a central repository mirror in each data centre with fairly strict policies about installing packages (only RPMs) not on the central repo but I'll enquire about letting me at least test installing from source as a test.
And.... what does the debug output of the *server* say?
From the RADIUS server debug on both versions the only difference I have seen between the old ver 1 and the new ver 3 is that the "Tunnel-Password" and the two "Cisco-AVPair" values are enclosed in single quote on ver 3 and double quotes on ver 1 The other difference I see is on the Cisco debug radius in that the test against the ver 1 server Cisco shows " RADIUS: Tunnel-Password [69] 53 00:*" but against ver 3 server it shows " RADIUS: Tunnel-Password [69] 52 00:*" - 53 verse 52 for the Tunnel-Password attribute length. The Tunnel-Password is just a 32 byte randomly generated string.
This is the "radiusd -Xxx" debug from the ver 3 server for the test I run on the Cisco router... Received Access-Request Id 21 from 172.16.0.1:1645 to 172.16.0.2:18122 length 57 User-Password = 'cisco' User-Name = 'user-name' NAS-IP-Address = 172.16.0.1 Mon Apr 18 15:38:27 2016 : Debug: (0) Received Access-Request packet from host 172.16.0.1 port 1645, id=21, length=57 Mon Apr 18 15:38:27 2016 : Debug: (0) User-Password = 'cisco' Mon Apr 18 15:38:27 2016 : Debug: (0) User-Name = 'user-name' Mon Apr 18 15:38:27 2016 : Debug: (0) NAS-IP-Address = 172.16.0.1 Mon Apr 18 15:38:27 2016 : Debug: (0) # Executing section authorize from file /etc/raddb-vpnclient_za/sites-enabled/default Mon Apr 18 15:38:27 2016 : Debug: (0) authorize { Mon Apr 18 15:38:27 2016 : Debug: (0) filter_username filter_username { Mon Apr 18 15:38:27 2016 : Debug: (0) if (!&User-Name) Mon Apr 18 15:38:27 2016 : Debug: (0) if (!&User-Name) -> FALSE Mon Apr 18 15:38:27 2016 : Debug: (0) if (&User-Name =~ / /) Mon Apr 18 15:38:27 2016 : Debug: (0) if (&User-Name =~ / /) -> FALSE Mon Apr 18 15:38:27 2016 : Debug: (0) if (&User-Name =~ /@.*@/ ) Mon Apr 18 15:38:27 2016 : Debug: (0) if (&User-Name =~ /@.*@/ ) -> FALSE Mon Apr 18 15:38:27 2016 : Debug: (0) if (&User-Name =~ /\\.\\./ ) Mon Apr 18 15:38:27 2016 : Debug: (0) if (&User-Name =~ /\\.\\./ ) -> FALSE Mon Apr 18 15:38:27 2016 : Debug: (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\\.(.+)$/)) Mon Apr 18 15:38:27 2016 : Debug: (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\\.(.+)$/)) -> FALSE Mon Apr 18 15:38:27 2016 : Debug: (0) if (&User-Name =~ /\\.$/) Mon Apr 18 15:38:27 2016 : Debug: (0) if (&User-Name =~ /\\.$/) -> FALSE Mon Apr 18 15:38:27 2016 : Debug: (0) if (&User-Name =~ /@\\./) Mon Apr 18 15:38:27 2016 : Debug: (0) if (&User-Name =~ /@\\./) -> FALSE Mon Apr 18 15:38:27 2016 : Debug: (0) } # filter_username filter_username = notfound Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: calling preprocess (rlm_preprocess) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [preprocess] = ok Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: calling chap (rlm_chap) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: returned from chap (rlm_chap) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [chap] = noop Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: calling mschap (rlm_mschap) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: returned from mschap (rlm_mschap) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [mschap] = noop Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: calling digest (rlm_digest) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: returned from digest (rlm_digest) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [digest] = noop Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: calling suffix (rlm_realm) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) suffix : Checking for suffix after "@" Mon Apr 18 15:38:27 2016 : Debug: (0) suffix : No '@' in User-Name = "user-name", looking up realm NULL Mon Apr 18 15:38:27 2016 : Debug: (0) suffix : No such realm "NULL" Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: returned from suffix (rlm_realm) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [suffix] = noop Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: calling eap (rlm_eap) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) eap : No EAP-Message, not doing EAP Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: returned from eap (rlm_eap) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [eap] = noop Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: calling files (rlm_files) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: returned from files (rlm_files) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [files] = noop Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: calling sql (rlm_sql) for request 0 Mon Apr 18 15:38:27 2016 : Debug: %{User-Name} Mon Apr 18 15:38:27 2016 : Debug: Parsed xlat tree: Mon Apr 18 15:38:27 2016 : Debug: attribute --> User-Name Mon Apr 18 15:38:27 2016 : Debug: (0) sql : EXPAND %{User-Name} Mon Apr 18 15:38:27 2016 : Debug: (0) sql : --> user-name Mon Apr 18 15:38:27 2016 : Debug: (0) sql : SQL-User-Name set to 'user-name' Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: FROM 1 TO 5 MAX 6 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: Examining SQL-User-Name Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: APPENDING SQL-User-Name FROM 0 TO 5 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: TO in 5 out 6 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[0] = User-Password Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[1] = User-Name Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[2] = NAS-IP-Address Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[3] = Event-Timestamp Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[4] = Huntgroup-Name Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[5] = SQL-User-Name Mon Apr 18 15:38:27 2016 : Debug: rlm_sql (sql): Reserved connection (4) Mon Apr 18 15:38:27 2016 : Debug: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: Parsed xlat tree: Mon Apr 18 15:38:27 2016 : Debug: literal --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = ' Mon Apr 18 15:38:27 2016 : Debug: attribute --> SQL-User-Name Mon Apr 18 15:38:27 2016 : Debug: literal --> ' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: (0) sql : EXPAND SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: (0) sql : --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'user-name' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: rlm_sql (sql): Executing query: 'SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'user-name' ORDER BY id' Mon Apr 18 15:38:27 2016 : Debug: (0) sql : User found in radcheck table Mon Apr 18 15:38:27 2016 : Debug: (0) sql : Check items matched Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: FROM 1 TO 0 MAX 1 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: Examining Cleartext-Password Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: APPENDING Cleartext-Password FROM 0 TO 0 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: TO in 0 out 1 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[0] = Cleartext-Password Mon Apr 18 15:38:27 2016 : Debug: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: Parsed xlat tree: Mon Apr 18 15:38:27 2016 : Debug: literal --> SELECT id, username, attribute, value, op FROM radreply WHERE username = ' Mon Apr 18 15:38:27 2016 : Debug: attribute --> SQL-User-Name Mon Apr 18 15:38:27 2016 : Debug: literal --> ' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: (0) sql : EXPAND SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: (0) sql : --> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'user-name' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: rlm_sql (sql): Executing query: 'SELECT id, username, attribute, value, op FROM radreply WHERE username = 'user-name' ORDER BY id' Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ... falling-through to group processing Mon Apr 18 15:38:27 2016 : Debug: SELECT groupname FROM usergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority Mon Apr 18 15:38:27 2016 : Debug: Parsed xlat tree: Mon Apr 18 15:38:27 2016 : Debug: literal --> SELECT groupname FROM usergroup WHERE username = ' Mon Apr 18 15:38:27 2016 : Debug: attribute --> SQL-User-Name Mon Apr 18 15:38:27 2016 : Debug: literal --> ' ORDER BY priority Mon Apr 18 15:38:27 2016 : Debug: (0) sql : EXPAND SELECT groupname FROM usergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority Mon Apr 18 15:38:27 2016 : Debug: (0) sql : --> SELECT groupname FROM usergroup WHERE username = 'user-name' ORDER BY priority Mon Apr 18 15:38:27 2016 : Debug: rlm_sql (sql): Executing query: 'SELECT groupname FROM usergroup WHERE username = 'user-name' ORDER BY priority' Mon Apr 18 15:38:27 2016 : Debug: (0) sql : User found in the group table Mon Apr 18 15:38:27 2016 : Debug: SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: Parsed xlat tree: Mon Apr 18 15:38:27 2016 : Debug: literal --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = ' Mon Apr 18 15:38:27 2016 : Debug: attribute --> Sql-Group Mon Apr 18 15:38:27 2016 : Debug: literal --> ' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: (0) sql : EXPAND SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = '%{Sql-Group}' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: (0) sql : --> SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'user-name-nas' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: rlm_sql (sql): Executing query: 'SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'user-name-nas' ORDER BY id' Mon Apr 18 15:38:27 2016 : Debug: (0) sql : Group "user-name-nas" check items matched Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: FROM 1 TO 1 MAX 2 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: Examining Huntgroup-Name Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: APPENDING Huntgroup-Name FROM 0 TO 1 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: TO in 1 out 2 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[0] = Cleartext-Password Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[1] = Huntgroup-Name Mon Apr 18 15:38:27 2016 : Debug: SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{Sql-Group}' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: Parsed xlat tree: Mon Apr 18 15:38:27 2016 : Debug: literal --> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = ' Mon Apr 18 15:38:27 2016 : Debug: attribute --> Sql-Group Mon Apr 18 15:38:27 2016 : Debug: literal --> ' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: (0) sql : EXPAND SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = '%{Sql-Group}' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: (0) sql : --> SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'user-name-nas' ORDER BY id Mon Apr 18 15:38:27 2016 : Debug: rlm_sql (sql): Executing query: 'SELECT id, groupname, attribute, value, op FROM radgroupreply WHERE groupname = 'user-name-nas' ORDER BY id' Mon Apr 18 15:38:27 2016 : Debug: (0) sql : Group "user-name-nas" reply items processed Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: FROM 5 TO 0 MAX 5 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: Examining Service-Type Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: APPENDING Service-Type FROM 0 TO 0 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: Examining Tunnel-Type Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: APPENDING Tunnel-Type FROM 1 TO 1 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: Examining Tunnel-Password Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: APPENDING Tunnel-Password FROM 2 TO 2 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: Examining Cisco-AVPair Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: APPENDING Cisco-AVPair FROM 3 TO 3 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: Examining Cisco-AVPair Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: APPENDING Cisco-AVPair FROM 4 TO 4 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: TO in 0 out 5 Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[0] = Service-Type Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[1] = Tunnel-Type Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[2] = Tunnel-Password Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[3] = Cisco-AVPair Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ::: to[4] = Cisco-AVPair Mon Apr 18 15:38:27 2016 : Debug: (0) sql : ... falling-through to profile processing Mon Apr 18 15:38:27 2016 : Debug: rlm_sql (sql): Released connection (4) Mon Apr 18 15:38:27 2016 : Info: rlm_sql (sql): Closing connection (0), from 1 unused connections Mon Apr 18 15:38:27 2016 : Debug: rlm_sql_mysql: Socket destructor called, closing socket Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: returned from sql (rlm_sql) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [sql] = ok Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: calling expiration (rlm_expiration) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: returned from expiration (rlm_expiration) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [expiration] = noop Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: calling logintime (rlm_logintime) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: returned from logintime (rlm_logintime) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [logintime] = noop Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: calling pap (rlm_pap) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authorize]: returned from pap (rlm_pap) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [pap] = updated Mon Apr 18 15:38:27 2016 : Debug: (0) } # authorize = updated Mon Apr 18 15:38:27 2016 : Debug: (0) Found Auth-Type = PAP Mon Apr 18 15:38:27 2016 : Debug: (0) # Executing group from file /etc/raddb-vpnclient_za/sites-enabled/default Mon Apr 18 15:38:27 2016 : Debug: (0) Auth-Type PAP { Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authenticate]: calling pap (rlm_pap) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) pap : Login attempt with password "cisco" Mon Apr 18 15:38:27 2016 : Debug: (0) pap : Comparing with "known good" Cleartext-Password "cisco" Mon Apr 18 15:38:27 2016 : Debug: (0) pap : User authenticated successfully Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[authenticate]: returned from pap (rlm_pap) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [pap] = ok Mon Apr 18 15:38:27 2016 : Debug: (0) } # Auth-Type PAP = ok Mon Apr 18 15:38:27 2016 : Auth: (0) Login OK: [user-name] (from client cavalier port 0) Mon Apr 18 15:38:27 2016 : Debug: (0) # Executing section post-auth from file /etc/raddb-vpnclient_za/sites-enabled/default Mon Apr 18 15:38:27 2016 : Debug: (0) post-auth { Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[post-auth]: calling exec (rlm_exec) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[post-auth]: returned from exec (rlm_exec) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [exec] = noop Mon Apr 18 15:38:27 2016 : Debug: (0) remove_reply_message_if_eap remove_reply_message_if_eap { Mon Apr 18 15:38:27 2016 : Debug: (0) if (&reply:EAP-Message && &reply:Reply-Message) Mon Apr 18 15:38:27 2016 : Debug: (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE Mon Apr 18 15:38:27 2016 : Debug: (0) else else { Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[post-auth]: calling noop (rlm_always) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) modsingle[post-auth]: returned from noop (rlm_always) for request 0 Mon Apr 18 15:38:27 2016 : Debug: (0) [noop] = noop Mon Apr 18 15:38:27 2016 : Debug: (0) } # else else = noop Mon Apr 18 15:38:27 2016 : Debug: (0) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop Mon Apr 18 15:38:27 2016 : Debug: (0) } # post-auth = noop Mon Apr 18 15:38:27 2016 : Debug: (0) Sending Access-Accept packet to host 172.16.0.1 port 1645, id=21, length=0 Mon Apr 18 15:38:27 2016 : Debug: (0) Service-Type = Outbound-User Mon Apr 18 15:38:27 2016 : Debug: (0) Tunnel-Type = ESP Mon Apr 18 15:38:27 2016 : Debug: (0) Tunnel-Password = 'xbHLhNm79ZNZi2CYw7TWFPSiRGX0Toee' Mon Apr 18 15:38:27 2016 : Debug: (0) Cisco-AVPair = 'ipsec:key-exchange=ike' Mon Apr 18 15:38:27 2016 : Debug: (0) Cisco-AVPair = 'ipsec:key-exchange=preshared-key' Sending Access-Accept Id 21 from 172.16.0.2:18122 to 172.16.0.1:1645 Service-Type = Outbound-User Tunnel-Type = ESP Tunnel-Password = 'xbHLhNm79ZNZi2CYw7TWFPSiRGX0Toee' Cisco-AVPair = 'ipsec:key-exchange=ike' Cisco-AVPair = 'ipsec:key-exchange=preshared-key' Mon Apr 18 15:38:27 2016 : Debug: (0) Finished request Mon Apr 18 15:38:27 2016 : Debug: Waking up in 0.3 seconds. Mon Apr 18 15:38:27 2016 : Debug: Waking up in 4.6 seconds. Mon Apr 18 15:38:32 2016 : Debug: (0) Cleaning up request packet ID 21 with timestamp +56 Mon Apr 18 15:38:32 2016 : Info: Ready to process requests
Please send me a packet trace from 1.1.3 and 3.0.4. Are you referring to a tcpflow to capture the traffic?
Rhys McWilliams ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
On 19 Apr 2016, at 09:33, McWilliams, Rhys <rhys.mcwilliams@cdk.com> wrote:
Hi Alan, Thanks for the quick reply...
Try 3.0.11. It has a number of issues fixed over 3.0.4. We run a central repository mirror in each data centre with fairly strict policies about installing packages (only RPMs) not on the central repo but I'll enquire about letting me at least test installing from source as a test.
So say we did find it was a defect in 3.0.4. How would you address that if you could only run the RHEL bundled version of FreeRADIUS? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi Arran
So say we did find it was a defect in 3.0.4. How would you address that if you could only run the RHEL bundled version of FreeRADIUS?
I guess we'd either have to postpone the server migration, which probably won't go down very well, or they'd have to let me install from source... Rhys McWilliams ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
On Tue, Apr 19, 2016 at 02:02:47PM +0000, McWilliams, Rhys wrote:
So say we did find it was a defect in 3.0.4. How would you address that if you could only run the RHEL bundled version of FreeRADIUS?
I guess we'd either have to postpone the server migration, which probably won't go down very well, or they'd have to let me install from source...
:) There is a .spec file shipped with FreeRADIUS, so you should be able to easily build RPM packages if that's what is required. But to test things, building and installing in, say, /opt/freeradius is clean - it won't put anything messy anywhere else on the system, so to get rid of it at the end you can just remove the directory you installed in to. I do this fairly often - install test copy in alternative location, stop live running packaged version, start test version. Watch to see if it works or not, then kill test version and start packaged version up again. Can easily test for a few seconds on a system without really disrupting anything or messing up any installed config. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi Mathew,
But to test things, building and installing in, say, /opt/freeradius is clean
Thanks, will probably give that a try and just sneak the source onto the server and test;) Rhys McWilliams Network Engineer IV CDK Global 29 Bond Street Randburg 2194 T: 011.998.6000 M: 082.335.5014 E: rhys.mcwilliams@cdk.com W: www.cdkglobal.co.za ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
On Apr 19, 2016, at 9:33 AM, McWilliams, Rhys <rhys.mcwilliams@cdk.com> wrote:
We run a central repository mirror in each data centre with fairly strict policies about installing packages (only RPMs) not on the central repo but I'll enquire about letting me at least test installing from source as a test.
You can (a) blindly follow a policy, or (b) have working software. Pick one.
From the RADIUS server debug on both versions the only difference I have seen between the old ver 1 and the new ver 3 is that the "Tunnel-Password" and the two "Cisco-AVPair" values are enclosed in single quote on ver 3 and double quotes on ver 1
That's just debug output. The point is to look at the actual packet traces... i.e. PCAP. I need to see what's on the wire.
This is the "radiusd -Xxx" debug from the ver 3 server for the test I run on the Cisco router...
Well, it works for me in the v3.0.x branch.
Please send me a packet trace from 1.1.3 and 3.0.4. Are you referring to a tcpflow to capture the traffic?
tcpdump or wireshark. tcpflow seems to be TCP only. Alan DeKok.
Hi Alan, I've managed to get tcpdump onto the new server and attached should be the output files from the following commands on both new and old servers, hopefully gives what you're looking for. tcpdump -nn -i eth0 -w /tmp/radius.tcpdump port 18122 Port 18122 of course being the port our radius is listening on... I did the test from the same Cisco router and had setup the clients.conf for that router to use the testing123 secret. I had a look at trying v3.11 but I see the server team have not installed any of the compiling tools and they're not available from the repository. I've put in a request to allow me to do this so hopefully it's approved soon... Rhys McWilliams ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
On Apr 20, 2016, at 7:56 AM, McWilliams, Rhys <rhys.mcwilliams@cdk.com> wrote:
I've managed to get tcpdump onto the new server and attached should be the output files from the following commands on both new and old servers, hopefully gives what you're looking for. tcpdump -nn -i eth0 -w /tmp/radius.tcpdump port 18122
Thanks.
Port 18122 of course being the port our radius is listening on...
I did the test from the same Cisco router and had setup the clients.conf for that router to use the testing123 secret.
I had a look at trying v3.11 but I see the server team have not installed any of the compiling tools and they're not available from the repository. I've put in a request to allow me to do this so hopefully it's approved soon...
I can't reproduce this on 3.0.11, so that version would seem to fix the problem. Alan DeKok.
Hi,
I had a look at trying v3.11 but I see the server team have not installed any of the compiling tools and they're not available from the repository. I've put in a request to allow me to do this so hopefully it's approved soon...
that'd be normal. use a build server to make the RPM and then install the RPM on your production server.... alan
On Wed, Apr 20, 2016 at 01:06:58PM +0000, A.L.M.Buxey@lboro.ac.uk wrote:
I had a look at trying v3.11 but I see the server team have not installed any of the compiling tools and they're not available from the repository. I've put in a request to allow me to do this so hopefully it's approved soon...
that'd be normal. use a build server to make the RPM and then install the RPM on your production server....
Yup, or build manually and install to /opt/freeradius on another server, then just copy all of /opt/freeradius over - saves messing with the installed RPM for a temporary check. Plenty of ways to do this :) You can even selectively proxy particular packets (e.g. based on calling-station-id or similar) over to a test server from the live server. I find that quite useful to keep configured for quickly checking things. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Yup, or build manually and install to /opt/freeradius on another server, then just copy all of /opt/freeradius over - saves messing with the installed RPM for a temporary check.
Okay, so I found a server running the same OS that had some of the dev tools and just had to install a few others that configure stopped for. I compiled and installed to /opt/freeradius as suggested and then copied the folder to one of my new RADIUS servers and got all hopeful... I ran "/opt/freeradius/sbin/radiusd -Xxx" and got a message about refusing to run with openssl ver 1.0.1e due to the heartbleed bug. Again, openssl was installed from the RPM managed repository so can't upgrade it, but this server is not accessible from the public Internet so we don't really care about the heartbleed bug. I did notice the output also showed to set "security.allow_vulnerable_openssl = 'CVE-2014-0160'" which I did and it then did not complain again about our version of openssl, thank you for including the option... However, when I now run "/opt/freeradius/sbin/radiusd -Xxx" it errors with the following Thu Apr 21 11:59:56 2016 : Debug: Loading rlm_digest with path: /usr/lib64/freeradius/rlm_digest.so Thu Apr 21 11:59:56 2016 : Debug: Loading rlm_digest failed: /usr/lib64/freeradius/rlm_digest.so: undefined symbol: debug_flag - No access errors Thu Apr 21 11:59:56 2016 : Debug: Loading library using linker search path(s) Thu Apr 21 11:59:56 2016 : Debug: Defaults : /lib:/usr/lib Thu Apr 21 11:59:56 2016 : Debug: Loaded rlm_digest, checking if it's valid Thu Apr 21 11:59:56 2016 : Debug: # Loaded module rlm_digest Thu Apr 21 11:59:56 2016 : Debug: # Loading module "digest" from file /etc/raddb/mods-enabled/digest Thu Apr 21 11:59:56 2016 : Debug: Loading rlm_dynamic_clients with path: /usr/lib64/freeradius/rlm_dynamic_clients.so Thu Apr 21 11:59:56 2016 : Debug: Loaded rlm_dynamic_clients, checking if it's valid Thu Apr 21 11:59:56 2016 : Error: /etc/raddb/mods-enabled/dynamic_clients[30]: Failed loading module rlm_dynamic_clients from file /usr/lib64/freeradius/rlm_dynamic_clients.so Thu Apr 21 11:59:56 2016 : Error: /etc/raddb/mods-enabled/dynamic_clients[30]: Application and rlm_dynamic_clients magic number (version) mismatch. application: 30011 module: 30004 I gather that's because it's looking in /usr/lib64/freeradius for the libraries instead of 3.11 verions in /opt/freeradius/lib Is there an easy temporary way to get this verion to use /opt/freeradius/lib or should I just rename /usr/lib64/freeradius and then create a link to /opt/freeradius/lib ? Rhys McWilliams ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
On Thu, Apr 21, 2016 at 11:29:39AM +0000, McWilliams, Rhys wrote:
Yup, or build manually and install to /opt/freeradius on another server, then just copy all of /opt/freeradius over - saves messing with the installed RPM for a temporary check.
Thu Apr 21 11:59:56 2016 : Debug: Loading rlm_digest with path: /usr/lib64/freeradius/rlm_digest.so ... I gather that's because it's looking in /usr/lib64/freeradius for the libraries instead of 3.11 verions in /opt/freeradius/lib Is there an easy temporary way to get this verion to use /opt/freeradius/lib or should I just rename /usr/lib64/freeradius and then create a link to /opt/freeradius/lib ?
raddb/radiusd.conf Look at the paths at the top, (prefix, etc) and make sure they are all correct for the new install. You might want to copy your entire raddb to /opt/freeradius/etc/raddb and then just edit the radiusd.conf there. Then a bit further down after a block of comment is "libdir". Compare radiusd.conf of your existing config with the one in /opt/freeradius/etc/raddb/radiusd.conf and you should easily see the differences. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
raddb/radiusd.conf
Look at the paths at the top, (prefix, etc) and make sure they are all correct for the new install. You might want to copy your entire raddb to /opt/freeradius/etc/raddb and then just edit the radiusd.conf there.
Then a bit further down after a block of comment is "libdir".
Thanks Matthew, that did it... An update and good news... Running on FreeRADIUS version 3.11 now, I no longer get that Cisco notice about " Tunnel-Password length not multiple of 16" so that now works, thank you all. I've got one more test to check but can only do it outside of customer business hours as I don't currently have a test client router available. The interesting bit now will be convincing the powers-that-be to either allow me to run the compiled v3.11 or for them to build an RPM and post it on the central management system... Rhys McWilliams ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
The interesting bit now will be convincing the powers-that-be to either allow me to run the compiled v3.11 or for them to build an RPM and post it on the central management system...
I would strongly recommend building an RPM. It is easy enough to manage. And if your management are concerned about compatibility with Redhat's version, you can always download their SRPM from Koji and build with that. :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
It is easy enough to manage. And if your management are concerned about compatibility with Redhat's version, you can always download their SRPM from Koji and build with that.
*ARGH* 'with that one's SPEC file' I meant to say. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On Apr 18, 2016, at 10:22 AM, McWilliams, Rhys <rhys.mcwilliams@cdk.com> wrote:
Apr 18 16:01:39 SAST: RADIUS: Tunnel-Password [69] 52 00:* Apr 18 16:01:39 SAST: RADIUS: Vendor, Cisco [26] 30 ... Apr 18 16:01:39 SAST: RADIUS: Tunnel-Password length not multiple of 16 Apr 18 16:01:39 SAST: RADIUS/DECODE: decoder; FAIL Apr 18 16:01:39 SAST: RADIUS/DECODE: attribute Tunnel-Password; FAIL Apr 18 16:01:39 SAST: RADIUS/DECODE: parse response op decode; FAIL
If I read that correctly, the decoder is broken. Tell Cisco to fix it. The debug output here shows that the length of the Tunnel-Password attribute is 52. 2 bytes are for the RADIUS header. 2 bytes are for the salt (RFC 2868 Section 3.5). The remaining *encrypted* portion is 48 bytes long... which is a multiple of 16. As it's supposed to be. Please send me a packet trace from 1.1.3 and 3.0.4. Use the standard secret "testing123", so I can decode the Tunnel-Password and look at the data. There *might* be a bug in 3.0.4, but I'm inclined towards believing that the Cisco implementation is wrong. Alan DeKok.
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Matthew Newton -
McWilliams, Rhys -
Stefan Paetow