Hi Fabrice, We have been using the default cisco switch template as non of our production switches have templates.
We have 3650 and 2960 in the lab. Kind Regards Simon Sent from my Galaxy -------- Original message -------- From: Fabrice Durand <oeufd...@gmail.com> Date: 21/01/2022 16:54 (GMT+00:00) To: Simon Sutcliffe <simon.sutcli...@rhdhv.com> Cc: packetfence-users@lists.sourceforge.net, Raghuram Kuricheti <raghuram.kurich...@rhdhv.com> Subject: Re: Challenge with sending filter-ID to Cisco switch This message was sent from a public domain email service such as Gmail, Yahoo!, AOL, etc. Please be cautious. Hello Simon, what switch module are you using in PacketFence ? It´s implemented here: https://github.com/inverse-inc/packetfence/blob/devel/lib/pf/Switch/Cisco/Catalyst_2960.pm#L580 Regards Fabrice Le ven. 21 janv. 2022 à 02:43, Simon Sutcliffe <simon.sutcli...@rhdhv.com<mailto:simon.sutcli...@rhdhv.com>> a écrit : Dear Team Over the last few weeks we have been engaged with trying to understand a problem we were facing. The problem was with sending a Filter-ID [Graphical user interface, text, application, chat or text message Description automatically generated] On the switch we had created a extended access list of the same name ip access-list extended Pre-Auth-For-Registration 10 permit ip 10.207.129.0 0.0.0.255 10.202.1.0 0.0.0.255 20 permit ip 10.207.129.0 0.0.0.255 10.202.5.0 0.0.0.255 30 deny ip 10.207.129.0 0.0.0.255 10.0.0.0 0.255.255.255 40 permit ip any any And during the MAB connection the radius response within the auditing section clearly showed that PF was sending the attribute along with the VLAN we wanted the client to be placed in. RADIUS Reply REST-HTTP-Status-Code = 200 Filter-Id = "Pre-Auth-For-Registration" Tunnel-Medium-Type = IEEE-802 Tunnel-Private-Group-Id = "7" Tunnel-Type = VLAN In the logging on the Cisco Switch you saw the Filter-ID was asl received. However on two Cisco Switches (3650 and 2960) we tested the VLAN was correctly actioned but the Filter-ID was ignored. The problem was identified as The ACL Filter-ID is not including the direction The solution to solve the case was to add an additional command in the switch config. #radius-server attribute 11 default direction inbound This forced the inbound Filter-ID to be assigned to the inbound ACL handle. After this the ACL could be clearly seen within the session and was actioned by the switch bsns-3750-5#show authentication sessions interface g1/0/1 Interface: GigabitEthernet1/0/1 MAC Address: 0050.5699.4ea1 IP Address: 192.168.2.200 User-Name: cisco Status: Authz Success Domain: DATA Security Policy: Should Secure Security Status: Unsecure Oper host mode: multi-auth Oper control dir: both Authorized By: Authentication Server Vlan Policy: 7 Filter-Id: Pre-Auth-For-Registration Session timeout: N/A Idle timeout: N/A Common Session ID: C0A800010000059E47B77481 Acct Session ID: 0x00000733 Handle: 0x5E00059F There is also this note in the Cisco documentation The Filter-Id attribute can be used to specify an inbound or outbound ACL that is already configured on the switch. The attribute contains the ACL number followed by .in for ingress filtering or .out for egress filtering. If the RADIUS server does not allow the .in or .out syntax, the access list is applied to the outbound ACL by default. Because of limited support of Cisco IOS access lists on the switch, the Filter-Id attribute is supported only for IP ACLs numbered 1 to 199 and 1300 to 2699 (IP standard and IP extended ACLs). @Fabrice Durand<mailto:oeufd...@gmail.com> This could be a point for your developers and documentation team to make a note to see if this can be solved with some direction information from PF. If not you have this information if another customer is facing the same challenge. Hope this was helpful and I appreciate your support on the other issues we are facing. Kind Regards Simon Royal HaskoningDHV - Internal Use Only This email and any attachments are intended solely for the use of the addressee(s); disclosure or copying by others than the intended person(s) is strictly prohibited. If you have received this email in error, please treat this email as confidential, notify the sender and delete all copies of the email immediately This email and any attachments are intended solely for the use of the addressee(s); disclosure or copying by others than the intended person(s) is strictly prohibited. If you have received this email in error, please treat this email as confidential, notify the sender and delete all copies of the email immediately
_______________________________________________ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
