Security

Running 6.3.1.8 on 7240's and 7220's.

So we implemented a packet fence solution for guest logon.

When the user gets the initial role of a captiveportal that only allows it to get to packet fence, he gets to the packet fence server, registers properly, and then I should receive a COA from packet fence on what new role to go to but keep the same IP.

When I finish the guest process in packetfence, I keep the same role of captive-portal and not get the right role under I clear myself from the user-table then I get the correct role.

Few questions:

A) in Aruba under the captive portal I have the roles of denyall set (to ensure I get the COA role of "guest" instead of the denyall - which does happen. So I conclude that the default role and default guest role under Authentication > L3 Auth > Captive Portal are not used because of the COA, correct?

B) To show information on COA messages coming through the local switch, I have informational logging for user facility subcat captive-portal/ dot1x/ radius and facility security subcat aaa. I also do the command "show aaa rfc-3576-server statistics" and neither yield any information. Stats show 0's and no logs. Any idea what log and/or command I can run to see these messages/ numbers going up?

C) Most importantly, clearly the COA is working from packet fence as I get the "guest" role after clearing myself from user-table (instead of the denyall role that's set in the captive portal profile). Why do I have to clear myself from user-table? Any work around?

I realize this mostly is implemented with the user hopping from one vlan to another after successful guest access which would change the user-table automatically... we're hoping the user keeps the same IP throughout but gets kicked from user-table to get the new role that packet fence provided - which isn't happening automatically....

Hope that all made sense - please let me know if any other info or explanation is necessary.

Thank you!!

Update,

COA isn't working - clearing the user-table makes the user re-register which puts me in the right group because of L2 Mac auth to the packetfence box (already registered at that point).

So the statistics on CoA are correct as we're not seeing CoA messages come in.

Make sure that the key use in the RFC profile matches 

Are you using a direct attribute instead of a server-derived rule to get from the PF attribute to the role?  Is the RFC3576 coming from the same IP as a defined RADIUS server for that AAA profile?  Over here the answer to both those questions is no, and what we've had to do is define the RFC3576 server as both an rfc server and a RADIUS auth/acct server in the AAA profile,  and then turn off the auth/acct instance we defined by using the "mode" switch which is apparently what they decided to call the enable/disable switch.

(We use disconnect-requests instead of CoAs but in theory you'd have

to do the same, because we do hop VLANs, but ISTR seeing CoAs work during initial testing.)

It has been a while but are you still using PacketFence?