I said:
>> After editing Aruba.pm to add sub supportsWiredMacAuth { return $TRUE; },
>> VLAN assignment "works,"This is an exaggeration. The Aruba controller caches the role and VLAN assignment for 5(?) minutes, even if there is a linkdown/linkup event. First, I need to figure out how to deauth the client, either through RADIUS, or command-line aaa user delete mac. I am less concerned about bouncing link because I can just make the DHCP leases really short, or tell the user to unplug. Francois: > This is why we force a bounce on wired interfaces. Unless using 802.1X > for which a re-authentication does the trick, you will have to bounce > the switchport in order to make it work. We are usually using the IF > MIB to do that (as you know). Well, we're using RADIUS macauth. The requests look just like open WiFi SSID requests, except that it's Ethernet-NoEAP rather than Wireless-802.11-NoEAP. How can I get PacketFence to try RFC3576 de-auth, which is working for both secure SSID and open SSID on the same controller? As it stands, a sniffer shows nothing at all: no SNMP, no radius-dynauth, no error in the logs. FWIW, I also have Cisco and NETGEAR switches using port-security and link-traps respectively, so I can't completely replace PacketFence innards. Below, I start "registered," then at 10:35 change to "unregistered," but the change doesn't take effect. Aug 16 10:09:03 pf::WebAPI(31849) INFO: handling radius autz request: from switch_ip => 1.2.6.100, connection_type => Ethernet-NoEAP mac => f0:de:ad:be:ef:74, port => 4996, username => f0-de-ad-be-ef-74 (pf::radius::authorize) Aug 16 10:09:03 pf::WebAPI(31849) INFO: MAC: f0:de:ad:be:ef:74, PID: rgraves, Status: reg. Returned VLAN: 184 (pf::vlan::fetchVlanForNode) Aug 16 10:35:13 pfcmd(2560) INFO: pfcmd calling node_modify for f0:de:ad:be:ef:74 (main::command_param) Aug 16 10:35:13 pfcmd(2560) INFO: re-evaluating access for node f0:de:ad:be:ef:74 (node_modify called) (pf::enforcement::reevaluate_access) Aug 16 10:35:13 pfcmd(2560) INFO: f0:de:ad:be:ef:74 is currentlog connected at 1.2.6.100 ifIndex 4996 in VLAN 184 (pf::enforcement::_should_we_reassign_vlan) Aug 16 10:35:14 pfcmd(2560) INFO: MAC: f0:de:ad:be:ef:74 is of status unreg; belongs into registration VLAN (pf::vlan::getRegistrationVlan) Aug 16 10:35:14 pfcmd(2560) INFO: VLAN reassignment required for f0:de:ad:be:ef:74 (current VLAN = 184 but should be in VLAN 965) (pf::enforcement::_should_we_reassign_vlan) Aug 16 10:35:14 pfcmd(2560) INFO: switch port for f0:de:ad:be:ef:74 is 1.2.6.100 ifIndex 4996 connection type: Wired MAC Auth (pf::enforcement::_vlan_reevaluation) > Another option would be to use the roles instead of VLANs. Everyone > would be on the same VLAN, but the role would be changed using CoA. > That would require some changes in the core code. Would it? Maybe I could edit vlan/custom.pm to detect connection_type => Ethernet-NoEAP on that specific switch, and *always* return the same VLAN regardless of reg/unreg/violation status. Of course, I would have to play NAT redirection games at the Aruba end in order to push the client to captive portal. And maybe hack at the captive portal code to force it to see the 93H wired clients as registration VLAN. And I wouldn't have an isolation VLAN. So, overall, not very attractive. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
