Some follow up, for those that are interested. Also, a couple of
questions.
We worked with the network and they discovered that our requests were
trying to assign an IP address (!), as far as the TNTs were concerned.
They had a filter up to deny any such requests (Framed-IP, which seemed
weird). They removed the filter, and the TNTs started assigning IPs as
they should. Keep in mind that attributes we set in the users file on the
auth server are the exact same we were using with our ICradius setup:
DEFAULT Auth-Type = System,
Service-Type = Framed-User,
Framed-Protocol = PPP,
Idle-Timeout = 900,
Session-Timeout = 4800,
Port-Limit = 6,
Framed-MTU = 1500
Here's what we saw going back and forth during testing (IP addresses
identified by 'nnn' for nas, 'ppp' for proxy and 'aaa' for auth):
rad_recv: Access-Request packet from host nnn.nnn.nnn.111:1681, id=215,
length=202
User-Name = "test@domain"
NAS-IP-Address = nnn.nnn.nnn.222
NAS-Port = 23523
NAS-Port-Type = Async
Service-Type = Framed-User
Framed-Protocol = PPP
Calling-Station-Id = "**********"
Ascend-Calling-Id-Type-Of-Num = Unknown
Ascend-Calling-Id-Number-Plan = Unknown
Called-Station-Id = "**********"
Acct-Session-Id = "395738553"
Ascend-Endpoint-Disc =
"\001\037\033\333ft&I\201\202\264\205T\213\3271\225\000\000\000"
Ascend-Data-Rate = 26400
Ascend-Xmit-Rate = 49333
User-Password = "*********"
Sending Access-Request of id 2 to aaa.aaa.aaa.aaa:1645
User-Name = "test@domain"
NAS-IP-Address = nnn.nnn.nnn.2222
NAS-Port = 23523
NAS-Port-Type = Async
Service-Type = Framed-User
Framed-Protocol = PPP
Calling-Station-Id = "**********"
Ascend-Calling-Id-Type-Of-Num = Unknown
Ascend-Calling-Id-Number-Plan = Unknown
Called-Station-Id = "**********"
Acct-Session-Id = "395738553"
Ascend-Endpoint-Disc =
"\001\037\033\333ft&I\201\202\264\205T\213\3271\225\000\000\000"
Ascend-Data-Rate = 26400
Ascend-Xmit-Rate = 49333
User-Password = ":\275\033\35304\335\305`8N\273\002\236I\375"
Proxy-State = "215"
rad_recv: Access-Accept packet from host aaa.aaa.aaa.aaa:1645, id=2, length=61
Service-Type = Framed-User
Framed-Protocol = PPP
Idle-Timeout = 900
Session-Timeout = 4800
Port-Limit = 6
Framed-MTU = 1500
Proxy-State = 0x323135
rad_check_password: Auth-Type = Accept, accepting the user
Login OK: [test@domain] (from client nnn.nnn.nnn.111 port 23523 cli **********)
Sending Access-Accept of id 215 to nnn.nnn.nnn.111:1681
Service-Type = Framed-User
Framed-Protocol = PPP
Idle-Timeout = 900
Session-Timeout = 4800
Port-Limit = 6
Framed-MTU = 1500
Framed-IP-Address = 255.255.255.254
Framed-Compression = Van-Jacobson-TCP-IP
Finished request 2
Going to the next request
So, the Framed-IP-Address and Framed-Compression are added by freeradius
somewhere. I can't find out where. These are normal a/v pairs, but they're
not coming from the auth server, and we don't have anything in the
rad*check or rad*reply, or the usergroup tables at all. It shouldn't be an
issue, but it was in this case.
Also, we didn't get anything back when the rejects happened from the NAS,
or anything in the radacct table, but it is logged in radius.log as a
completed login on both the auth and proxy servers (as shown in the
snippet above).
So, are these bugs or features?
thanks,
Jim
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
