[RADIATOR] Issues with Tacacs/Radius and v6 conversion

Wed Jan 26 09:08:00 CST 2011

First, thanks for responding.

> > I've recently tried to get a new radiator enviroment working with FreeBSD
> 8.1, Perl 5.10 and Radiator 4.7 with current patches.
> >
> > Most stuff work as expected but I've ran into a small snag with my setup. I
> need to use a Handler to catch Calling-Station-Id but for some reason all
> Calling-Station-Id that end up in accounting and level 4 logs begin there ip
> with "::ffff:". The only IPs that exist on the machine are ipv4.
> > For some reason the Calling-Station-Id field becomes to short to handle this
> and up with something like " ::ffff:111.11.1 " <-- this is the correct number of
> characters replaced with 1s to protect internal information.
> > I've only been able to verify this issue with Tacacs so far.. maybe it's
> different with Radius calls.
> 
> Is this pure RADIUS or something that has been converted from TACACS+?

>From what I can tell it's only on Tacacs+ messages, but as I mentioned before, I haven't seen it on Radius yet but that doesn't mean that its not the same there.

> You may have already known this, but I thought I'd mention it anyways.

Yep, aware of that :)

> > The same issue appear in Level 4 trace with tacacs
> > Example
> > "
> > Wed Jan 11 11:12:13 2011: DEBUG: TacacsplusConnection Authorization
> REQUEST 6, 15, 1, 1, scrambled, telnet111, ::ffff:111.11.1, 2, service=shell
> cmd=
> > "
> >
> > So I'm guessing it has to do with Tacacs not radius ?
> 
> Well, it depends :)
> 
> This line indicates that the mapped address had been packed in the
> incoming Tacacs request that is just being handled. So it looks like
> some entity is creating Tacacs requests that contain IPv4-Mapped IPv6
> Addresses.
> 
> Can you describe your setup and environment a little better. What device
> is creating Tacacs messages, please post your configuration (no secrets)
> and more complete log entries that show how messages are handled,
> especially those that contain the ::ffff: prefix.

It's pretty strait forward, I think. We have a Extreme and a Brocade(Foundry) device that try to authenticate a user on the tacacs server running in Radiator.
Config for the extreme is as follows
"
configure tacacs primary shared-secret <secret-key>
configure tacacs primary server <server-ip> client-ip <client-ip> vr <VR-A>
configure tacacs-accounting primary shared-secret <secret-key>
configure tacacs-accounting primary server <sefver-ip> client-ip <client-ip> vr <VR-A>
"

The Brocade have a similar configuration ofc :)

Radiator is almost as simple but simply to many rows to paste in here.. but it's pretty much the same as in the example configurations from "goodies".. and as far as authentication goes it's working as intended.

> > Anyone else seen this or have it working somewhere that doesn't show
> this ?
> >
> > Perhaps a fix ?
> 
> A fix might involve checking AI_V4MAPPED related socket options, as
> specified by RFC 3493, but if you could provide more information abouth
> e.g., the Tacacs message sender, that would help to tell if the fix is
> needed by Radiator or something else.
> 
> Socket interfaces have implementation specific differences and this is
> one of those "interesting" areas :)
> 
> So please tell us more, your configuration, log snippet and general
> setup would be very useful.

As for configuration see above.

Trace 4 log
---
*** Reply to TACACSPLUS request:
Code:       Access-Accept
Identifier: UNDEF
Authentic:  <snip>
Attributes:
        Service-Type = Administrative-User
<snip>

Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection result Access-Accept
Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Authentication REPLY 1, 0, ,
Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection disconnected from 111.11.111.111:34801
Wed Jan 26 15:55:43 2011: DEBUG: New TacacsplusConnection created for 111.11.111.111:41205
Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection request 192, 2, 1, 0, 1763071228, 57
Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Authorization REQUEST 6, 15, 1, 1, <snip>, telnet175, ::ffff:111.11.1, 2, service=shell cmd=
Wed Jan 26 15:55:43 2011: DEBUG: AuthorizeGroup rule match found: permit service=shell cmd= { priv-lvl=15 }
Wed Jan 26 15:55:43 2011: INFO: Authorization permitted for <snip> at 111.11.111.111, group manager, args service=shell cmd=
Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Authorization RESPONSE 1, , , priv-lvl=15 priv-lvl=15
Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection disconnected from 111.11.111.111:41205
Wed Jan 26 15:55:43 2011: DEBUG: New TacacsplusConnection created for 111.11.111.111:60789
Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection request 192, 3, 1, 0, 1553834616, 75
Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Accounting REQUEST 2, 6, 15, 1, 1, <snip>, telnet175, ::ffff:111.11.1, 2, start_time=1296053322 service=shell
Wed Jan 26 15:55:43 2011: DEBUG: TACACSPLUS derived Radius request packet dump:
Code:       Accounting-Request
Identifier: UNDEF
Authentic:  <snip>
Attributes:
        NAS-IP-Address = 111.11.111.111
        NAS-Port-Id = "telnet175"
        Calling-Station-Id = "::ffff:111.11.1"
        NAS-Identifier = "TACACS"
        User-Name = "<snip>"
        Acct-Status-Type = Start
        Acct-Session-Id = "1553834616"
        cisco-avpair = "start_time=1296053322"
        cisco-avpair = "service=shell"
        OSC-Version-Identifier = "192"

Wed Jan 26 15:55:43 2011: DEBUG: Handling request with Handler '', Identifier 'HandlerIdentTacacs'
Wed Jan 26 15:55:43 2011: DEBUG: Handling with Radius::AuthLDAP2: <snip>
Wed Jan 26 15:55:43 2011: DEBUG: AuthBy LDAP2 result: ACCEPT,
Wed Jan 26 15:55:43 2011: DEBUG: Accounting accepted
Wed Jan 26 15:55:43 2011: DEBUG: Packet dump:
*** Reply to TACACSPLUS request:
Code:       Accounting-Response
Identifier: UNDEF
Authentic:  <snip>
Attributes:

Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection result Accounting-Response
Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Accounting REPLY 1, ,
Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection disconnected from 111.11.111.111:60789
---
The the log.. snipped out a few things and changed the ip to 111s ;)

As far as I can tell the rem_addr is getting limited by rem_addr_len in ServerTACACS.pm .. but that in it self might not be it ?

Did a Trace 5 dump too.. but that doesn't seem to reveal anything that the trace 4 dump doesn't.

Thanks again,
Patrik Forsberg