No, you are not wrong, but I am not talking about applying an access list to a SVI, but to the VLAN itself using VLAN access maps. Again, my knowledge of such implementations is fuzzy. Given that the needs of the isolation and registration networks are very specific and fairly static, I would assume that this might be a reasonable approach.
This is what I am referring to: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_55_se/configuration/guide/swacl.html#wpxref58493 Thanks, Brent From: Francois Gaudreault [mailto:[email protected]] Sent: Wednesday, June 29, 2011 11:58 AM To: [email protected] Subject: Re: [Packetfence-users] Solitary confinement in the isolation and registration VLANs Brent, Correct me if I am wrong, but if you apply the ACL on the VLAN interface, it will not have any effect since the traffic is not going through that interface, it's not routed. In my solution, you need to create the ACL on all access switched. The other option would be to push stuff using the RADIUS VSA ip:inacl, but that requires the port to be in 802.1X single-host mode. Another solution would be to create a permanent ACL applied on the ports that matches the source ip subnet of isolation, and don't touch the traffic if the source is different. Again, that requires to have the ACL created on all access switches. On 11-06-29 11:45 AM, Brent Knotts wrote: Francois, Sounds intriguing, but I am not seeing a benefit over simply applying an access-list to the isolation VLAN. The painful part of that implementation is maintaining the access list separately on all access-layer switches. Your proposed solution requires that as well, right? I am not terribly acquainted with VLAN maps in actual practice, so there may be other issues I am not considering. Thanks, Brent From: Francois Gaudreault [mailto:[email protected]] Sent: Wednesday, June 29, 2011 11:28 AM To: [email protected]<mailto:[email protected]> Subject: Re: [Packetfence-users] Solitary confinement in the isolation and registration VLANs Hi Brent, Interesting question. I may have a solution to this, but I did not tested it, so maybe you can help on that topic. I know that we can send per-user ACL using RADIUS attributes. However, per-user ACL are not working when the 802.1X port is in multi-domain or multi-host mode, it does work using single-host mode. We experimented that in the lab recently. The thing I am thinking is : what about putting the entire port into a pre-defined access-list on the switch? I am not sure if this is considered per-user ACL. Basically, we create an ACL that allows traffic to the media gateway (if VoIP on the port), and allow HTTP/HTTPS traffic to PacketFence Isolation interface only (drop the rest). When we isolate a device, using RADIUS, we should be able to push such information using the ip:traffic-class VSA (ie. ip:traffic-class=in access-group name). There would be a way to test it in RADIUS using unlang without modifying the PF code. Something like (not tested) : if (%{Tunnel-Private-Group-Id} = 203} { update reply { Cisco-avpair = "ip:traffic-class=in access-group name" } } If the RADIUS way is not working, maybe we can do it via SNMP. Let me know what you think. On 11-06-29 10:44 AM, Brent Knotts wrote: I currently have PacketFence deployed (2.2.0, using 802.1x) on one VLAN as a beta implementation, with currently just over 100 devices on it. When finally deployed, the numbers will reach several thousand nodes over dozens of VLANs. One of the primary reasons for implementing this solution is to be able to quickly, remotely, and perhaps automatically, provide isolation in the case of a malware epidemic. However in the current state of implementation the isolation VLAN, while providing isolation from the active production networks, does not isolate the devices from one another. The isolation network would quickly become a haven for reinfection (not to mention that worm traffic would likely saturate uplinks). Also, the registration network could experience the same issues, or the large common VLAN could be abused for file sharing or other activities. I was wondering what users are doing to remedy this issue. My first thought was to use private VLANs, as they scale well across a large number of switches, but then I read this: You can configure IEEE 802.1x port-based authentication on a private-VLAN port, but do not configure IEEE 802.1x with port security, voice VLAN, or per-user ACL on private-VLAN ports. Apparently you can use private VLANs with 802.1x with VLAN assignment, but not with voice and only if all possible VLANs are private VLANs. This does not work for my environment. So my current thinking is to use VLAN maps (VACLs) to filter traffic on the isolation and registration VLANs. I would allow traffic back and forth to the PacketFence server (for DHCP, DNS, HTTP, etc.), and to any other services that monitor or provide remediation resources for these networks. This would be a bit more painful to maintain than private VLANs, but I do not expect this configuration to change much. Is there a better way to accomplish the isolation of unregistered or problem hosts? Is there some reason my intended implementation will not work? Has anyone solved this problem in a different way? Thanks, Brent ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Packetfence-users mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/packetfence-users -- Francois Gaudreault, ing. jr [email protected]<mailto:[email protected]> :: +1.514.447.4918 (x130) :: www.inverse.ca<http://www.inverse.ca> Inverse inc. :: Leaders behind SOGo (www.sogo.nu<http://www.sogo.nu>) and PacketFence (www.packetfence.org<http://www.packetfence.org>) ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Packetfence-users mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/packetfence-users -- Francois Gaudreault, ing. jr [email protected]<mailto:[email protected]> :: +1.514.447.4918 (x130) :: www.inverse.ca<http://www.inverse.ca> Inverse inc. :: Leaders behind SOGo (www.sogo.nu<http://www.sogo.nu>) and PacketFence (www.packetfence.org<http://www.packetfence.org>)
<<inline: image001.png>>
------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
