Correos (Spanish Post) has purchased some AP5131 to provide HQ's wifi service. They want to use user-based VLAN assignment via a NAC server from Enterasys. Well, AP5131, as far as I know, do not support NAC and so I told them (Dynamic VLAN is supported via a Cisco box whose name I don't remember). But RFS7000 do support NAC. And so I told them too of course. They have 8 unused RFS7000, so they could use one or two of them. The idea was creating an Extended WLAN with one ESSID and all of the user-based VLANs and applying it to AP5131 working in adaptive mode. In theory this should work: all the trafiic should flow from/to the RFS7000 and it would handle NAC stuff. But... Despite WLAn is extended and NOT independent, authentication Radius (NAC in reality) traffic is not encapsulated then forwarded to the RFS7000, but instead goes directly from AP to NAC. Actually, we had to set up AP5131 IP address on NAC, in its clients list. Since known authenticator is AP5131, then NAC sends to it all of the VLAN assignment stuff... which is obviously ignored, as expected. So, how could we force RFS7000 being the real authenticator to NAC server instead of AP5131? Without replacing AP5131 with AP650, please :). I already suggested to them. I was guessing about setting RFS7000 internal radius as NAC's proxy, and WLAN's Radius setting to RFS7000's IP address. This way, when authenticating, AP5131 would contact RFS7000 which in its turn would ask NAC. So NAC only has to "see" RFS7000. Would this work?
Extended WLAN on AAP5131 and NAC user-based VLAN assignment |
0 Replies