accounting with 802.1X: some clients trigger multiple starts at a time
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, We're running SQL accounting for the FR servers authenticating our 802.1X users, now. I'm seeing some annoying duplicate entries, and am wondering if anyone else has had this experience: mysql> SELECT acctsessionid, username, nasipaddress, acctstarttime, callingstationid FROM radacct WHERE acctstoptime IS NULL ORDER BY acctstarttime; +-----------------------------------+------------+-----------------+---------------------+------------------+ | acctsessionid | username | nasipaddress | acctstarttime | callingstationid | +-----------------------------------+------------+-----------------+---------------------+------------------+ ... | 4a15bfef/00:23:12:07:e9:c4/74507 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | 192.168.2.17 | | 4a15bfef/00:23:12:07:e9:c4/74505 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | w.x.38.213 | | 4a15bfef/00:23:12:07:e9:c4/74514 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | 10.250.61.133 | | 4a15bfef/00:23:12:07:e9:c4/74516 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | 192.168.1.25 | | 4a15bfef/00:23:12:07:e9:c4/74513 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | w.x.38.213 | ... I would think this to be pretty normal-looking, except: 1) in this particular group, all the usernames and MAC components of the acctsessionid are the same (i.e., this is one node causing multiple accounting starts to be sent); and 2) our 802.1X wireless clients would not have IP addresses in RFC1918 space. Ever. Most of the time, a group like this will include an address in our real wireless address range (that's what I've replaced with "w.x.38.213"), but sometimes not. If the callingstationid weren't different for each entry, I'd think "retries" or "EAP-FAST". (I think I see EAP-FAST activity going on elsewhere; or, at least, that's what I assume it is.) As far as I can tell, this occurs pretty infrequently, given the number of users we have, but it does occur consistently for a given set of users in a given day, which makes me think it's something about their location on the network. Reducing all the accounting detail to a spreadsheet, I see that this is a flurry of start and stop messages (and one Interim-Update!), and will comb through that closely tomorrow morning. Seems odd, though, that there would be a stop logged to the detail, but not to SQL, in this case. I have little- to no visibility into the networking configuration (our systems and network groups bristle at each other; a situation I'm trying to remedy), but I do know this: One department is located across the street from our main campus. It connects to the Internet by way of a commodity ISP. It is, however, close enough to pick up one of our APs, and the enterprising IT guy for that department has set up a Windows box as a wireless client, and bridged that into their LAN for access to institutional resources. (He has been duly chastised for this.) In at least that case, I've seen their LAN IPs (in a reasonably-unusual RFC1918 subnet) as the callingstationid. (Oddly, though, this is sometimes the LAN IP of their print server, or default gateway -- some artifact of bridging?) This makes me think that there are more clients out there that can see more than one subnet at a time, and just report in with whatever IP they feel like. I suppose my real question is this: Is there anything I can do, from the FR server end, to winnow out one reliable accounting entry per event? Sure, I can make my reports (like 'radwho') filter WHERE callingstationid LIKE 'w.x.%', but that runs the risk of missing entries where the group fails to include one of our "legit" addresses. Alternatively, has anyone else faced this and addressed it on the client side? ("Tell the rogue departments to comply with your network policies," is a valid answer and, frankly, my favorite.) As ever, pointers to pre-existing threads answering this are welcome; I couldn't come up with the right combination of search terms to find them myself... Cheers, - -sth sam hooker|sth@noiseplant.com|http://www.noiseplant.com Are you satisfied? ([y]/n): -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5) iEYEARECAAYFAkoVzbIACgkQX8KByLv3aQ3tVQCdEOfZCztHLnmvCvfiuax1Y6Qu pA0AoLhQLZCIP/0DwXWje1PY41suMq8o =JDqP -----END PGP SIGNATURE-----
Sam Hooker wrote:
We're running SQL accounting for the FR servers authenticating our 802.1X users, now. I'm seeing some annoying duplicate entries, and am wondering if anyone else has had this experience: ... | 4a15bfef/00:23:12:07:e9:c4/74507 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | 192.168.2.17 | | 4a15bfef/00:23:12:07:e9:c4/74505 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | w.x.38.213 | | 4a15bfef/00:23:12:07:e9:c4/74514 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | 10.250.61.133 | | 4a15bfef/00:23:12:07:e9:c4/74516 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | 192.168.1.25 | | 4a15bfef/00:23:12:07:e9:c4/74513 | [redacted] | 10.246.207.234 | 2009-05-21 16:56:15 | w.x.38.213 |
Hmm.. everythings the same but calling-station-id. My $0.02 is that the NAS is broken (big surprise). It's likely doing DHCP snooping to determine session IP address. However... this seems to result in it sending Accounting-Start for every different IP it sees. Or, it's just confused about what IP the client has.
I would think this to be pretty normal-looking, except:
1) in this particular group, all the usernames and MAC components of the acctsessionid are the same (i.e., this is one node causing multiple accounting starts to be sent); and
Remember: The NAS sends accounting packets whenever it wants. The contents of the accounting packets are determined SOLELY by the NAS.
2) our 802.1X wireless clients would not have IP addresses in RFC1918 space. Ever. Most of the time, a group like this will include an address in our real wireless address range (that's what I've replaced with "w.x.38.213"), but sometimes not.
The clients MAY be requesting those IPs. e.g. The user takes a laptop home, it gets a private IP. When he shows back up at work, the OS may try to first renew that IP... and when it gets no response, ask for a different IP. A badly written NAS may send accounting start packets for every DHCP packet. Especially if it's oing DHCP snooping. So the big question is: what NAS is causing the problem?
Reducing all the accounting detail to a spreadsheet, I see that this is a flurry of start and stop messages (and one Interim-Update!), and will comb through that closely tomorrow morning. Seems odd, though, that there would be a stop logged to the detail, but not to SQL, in this case.
The detail module doesn't care about the contents of the packet. The SQL module does. If it doesn't like the contents, it won't log it.
I have little- to no visibility into the networking configuration (our systems and network groups bristle at each other; a situation I'm trying to remedy), but I do know this: One department is located across the street from our main campus. It connects to the Internet by way of a commodity ISP. It is, however, close enough to pick up one of our APs, and the enterprising IT guy for that department has set up a Windows box as a wireless client, and bridged that into their LAN for access to institutional resources. (He has been duly chastised for this.)
Ugh. That might have affected it.
In at least that case, I've seen their LAN IPs (in a reasonably-unusual RFC1918 subnet) as the callingstationid. (Oddly, though, this is sometimes the LAN IP of their print server, or default gateway -- some artifact of bridging?) This makes me think that there are more clients out there that can see more than one subnet at a time, and just report in with whatever IP they feel like.
No... it's most likely the IP in the DHCP packet.
I suppose my real question is this: Is there anything I can do, from the FR server end, to winnow out one reliable accounting entry per event? Sure, I can make my reports (like 'radwho') filter WHERE callingstationid LIKE 'w.x.%', but that runs the risk of missing entries where the group fails to include one of our "legit" addresses.
Maybe suppress multiple accounting starts in the same second?
Alternatively, has anyone else faced this and addressed it on the client side? ("Tell the rogue departments to comply with your network policies," is a valid answer and, frankly, my favorite.)
Tell the rogue department to buy an AP that works.
As ever, pointers to pre-existing threads answering this are welcome; I couldn't come up with the right combination of search terms to find them myself...
It's a pretty esoteric problem. I'll add this to my list of "stupid things AP vendors do". Alan DeKok.
participants (2)
-
Alan DeKok -
Sam Hooker