accounting with 802.1X: some clients trigger multiple starts at a time

[Alan DeKok]

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.