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 <[email protected]> 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 > > > > [image: 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 <[email protected]> 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 >
_______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
