From: Sam Lai (LaiS@transnet.com)
Date: Sun Sep 17 2006 - 20:46:01 ART
2nd,
Typically you can define a "guest-vlan" for non-dot1x compliant client
or unauthenticated client and apply a very restricted ACL (deny ip any
any??) on this guest vlan. And based on the authenticated user
privilege/group, you have the following options:
1) Dynamic VLAN assignment - the switchport that the user machine
connected and dot1x authenticated will be assigned the corresponding
VLAN accordingly. For example, Accounting User group will be assigned
with VLAN 120, and Engineering Team will be assigned with VLAN 512. And
you can apply different ACL to these VLAN SVIs; whatever you want to do
with them.
2) User-based ACLs - a per-user ACL will be downloaded from ACS to the
switchport accordingly. For example, Students will be applied with an
ACL permitting only http/https, while Teachers will be applied with an
ACL permitting http/https/ftp/ntp etc.
But for all these fancy stuff to work, you will need 802.1x compliant
hosts, authenticators (i.e. 2950/3550/3750 switches), and a RADIUS
server (i.e. MCIAS 2K/2K3, FUNK, or CSACS 3.3 and up) at the minimal.
Hope it helps~
Sam
Sam Lai, CCIE CISSP
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
2nd CCIE
Sent: Sunday, September 17, 2006 2:22 PM
To: Sam Lai; sabrina pittarel
Cc: security@groupstudy.com; ccielab@groupstudy.com
Subject: RE: 3550 ACL's ..
Hi folks ;
thanks for this useful inputs ..i already seen the Docs which is sent
by Sabrina ...however what confused me was that i found the dynamic
keyword of the ACL already available and the switch did not reject the
configuration ...i agree also that the dyanmic ACL works just as if the
dyanmic keword is not there
now im pretty much convinced that what i try to achieve is not
possible this way ...
Sam ..can you give some guidance how to achieve that using dot1x ? ..i
want to do authentication for certain user and based on that the user
can forward his traffic to certain server ..not before authentication
thanks
Sam Lai <LaiS@transnet.com> wrote:
Hi 2nd CCIE,
1) I agree that IP ACL can be applied on the L2 interfaces in general.
However, the "Lock and Key" option (dynamic ACL) does not have any
affect. In fact, if you apply an ACL with dynamic entries on a L2
interface, the dynamic keyword is ignored. For example, if you apply an
ACL as such -
###############
ip access-list extended port_lock
10 permit tcp any host 172.16.1.254 eq telnet
20 dynamic timeout 1 permit ip any any
30 deny ip any any
interface Fa0/12
description R3
switchport access vlan 100
switchport mode access
ip access-group port_lock in
interface Vlan 100
ip address 172.16.1.254 255.255.255.0
###############
Note: 172.16.1.254 is your CAT1 Vlan100 IP Address. Interface Fa0/12 is
where you connect your host (R3).
The net result is that the entry #20 will be interpreted as "permit ip
any any" instead of what it seems.
Btw, I am using a 3550-PWR with IOS release
c3550-ipservicesk9-mz.122-25.SEE1.
2) What you are trying to accomplish is pretty much what dot1x offers in
general. Host/Port-based Authentication without dot1x, CCA/NAC or VMPS
is not quite possible. Look - you are trying to authenticate host/user
against L2 access (access within the same VLAN) over L3 (lock and key).
The logic of this idea is already corrupted when you have to allow L3
(implicitly allowing L2) for authentication. That's why we have dot1x as
a common solution.
2cents.
Sam
Sam Lai, CCIE CISSP
TransNet Corporation
Mobile 908.413.5466
Email LaiS@TransNet.com
________________________________
From: nobody@groupstudy.com on behalf of 2nd CCIE
Sent: Sun 9/17/2006 8:03 AM
To: sabrina pittarel; Subhash P; George Carr
Cc: 2nd CCIE; security@groupstudy.com; ccielab@groupstudy.com
Subject: Re: 3550 ACL's ..
here is my observation .
first the IP ACL can be applied on the L2 interfaces according ot the
Docs , however it will apply only on the inbound direction ( to the
switch ) which means it can filter the outbound traffic of certain host
..not the inbound traffic which is the case i wanted to achieve , in
your scenario it will work because you applied the ACL on the direction
to filter the echo-replies from the host ...this is ok
second observation is that if the IP ACL is applied on the logical
interface (interface vlan ) will take effect only if the traffic is
passing L3 boundary on the switch..not traffic bridged on the same vlan
.
to achieve filtering on the outbound direction ( filtering traffic going
To a host ) is combination between L3 ACL and vlan access-map ...i have
tested this and it works as per expection .....but here what i want to
achieve
i have this scenario .....R3---------------SW------------host ...they
are all on same Vlan .
R3 is connected to the outside world ..I want to configure a lock and
key ACL where ICMP traffic should be forwarded to the host after a user
get authenticated on the switch
now if i configured L3 ACL on the l2 port of the host ...the dynamic
entry of the ACL will not be triggered when i telnet to the switch .
if i applied the L3 ACL on the switch vlan interface ...the traffic will
keep passing to the host because it comes from R3 (same vlan ) either
applying it or not does not matter .
my question ..is this actually possible or not ...if yes ..how ?
sabrina pittarel wrote:
Sorry to chip in,
but what you are stating here is incorrect.
Have you tried it out?
On the 3550 a regular IP ACL, standard and extended, can be applied in
*ingress direction only* to a switchport.
This is from the DocCD:
Port ACLs You can also apply ACLs to Layer 2 interfaces on a switch.
Port ACLs are supported on physical interfaces only and not on
EtherChannel
interfaces. Port ACLs are applied on interfaces for inbound traffic
only.
These access lists are supported on Layer 2 interfaces:
b"Standard IP access lists using source addresses
b"Extended IP access lists using source and destination addresses and
optional protocol type information
b"MAC extended access lists using source and destination MAC addresses
and optional protocol type information
http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12225see/scg/s
wacl
.htm#wp1135301
2nd CCIE,
about you problem, not sure what's wrong but what I can say to you is
that it
works.
My Topology
139.1.0.0/24
.3 .6
R3 ------ SW (vlan367) -------- R6
0/3 0/6
f0/6 has an ACL applied to drop ICMP echo-replies from R6 toward R3.
R3:
With the ACL configured on SW:
-------------------------------
R3#ping 139.1.0.6 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 139.1.0.6, timeout is 2 seconds:
............................
Success rate is 0 percent (0/28)
R3#ping 139.1.0.6 repeat 1000
Without the ACL configured on SW:
-------------------------------------
R3#ping 139.1.0.6 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 139.1.0.6, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (959/959), round-trip min/avg/max = 1/2/4 ms
SW:
SW1#sh run int f0/3
Building configuration...
Current configuration : 96 bytes
!
interface FastEthernet0/3
switchport access vlan 367
switchport mode dynamic desirable
end
SW1#sh run int f0/6
Building configuration...
Current configuration : 120 bytes
!
interface FastEthernet0/6
switchport access vlan 367
switchport mode dynamic desirable
ip access-group 100 in
end
SW1#sh access
SW1#sh access-list 100
Extended IP access list 100
10 deny icmp host 139.1.0.6 host 139.1.0.3 echo-reply
20 permit ip any any
SW1#
Sabrina
----- Original Message ----
From: Subhash P
To: George Carr
Cc: 2nd CCIE ; security@groupstudy.com;
ccielab@groupstudy.com
Sent: Saturday, September 16, 2006 7:24:53 PM
Subject: Re: 3550 ACL's ..
You are perfect.
Subhash.
On 9/17/06, George Carr wrote:
>
> It appears to me that the primary problem is that you are trying to
filter
> on L3 at an interface that only has a L2 function in the conversation.
> ip ACL's will work on routed interfaces because they are L3 interfaces
> much
> like those in any router. For a 3550 to be routed (L3) interface its
> interface
> configuration must begin with the line 'no swichport' yours begins
with
> 'switchport access vlan 16'.
>
> As for using the VLAN SVI for filtering, here again for the most part
a
> VLAN
> is an L2 animal. the SVI's are like the router interfaces that lead to
and
> from
> the L2 segment that is defined by the ports assigned to be in that
VLAN.
> The only way I can think of an that a VLAN SVI would be useful for
> applying
> ip ACL's to
> would be if:
> - the devices in the VLAN it represents were configured to use its IP
> address as a default gateway
> - and the devices you were trying to filter were in a diferent VLAN or
a
> subnet accessible through some other routing device connected to the
> switch.
> - and you were running some L3 routing protocol on the 3550
>
> In other words
> - if the devices you are trying to filter are also in VLAN 16 then the
> switch is only a L2 participant in the conversation.
> - if the devices are on a different subnet / VLAN and / or device and
the
> default gateway on the servers is not the ip of the VLAN 16 SVI then
> again the 3550 is only providing a L2 path to whatever device is
> configured to be the dg for the server and does not even look at the
L3
> information in the packet.
>
> Call me crazy but you can't filter a L2 conversation with an ip access
> list,
> ip is L3.
>
> - GLC
>
>
> ----- Original Message -----
> From: "2nd CCIE"
> To:
> Cc: ;
> Sent: Saturday, September 16, 2006 2:14 PM
> Subject: Re: 3550 ACL's ..
>
>
> > Ok ..I have tried to apply the ACL on the interface vlan in both
> > directions ..i still able to ping the server .
> >
> > what am i missing ?
> >
> >
> >
> > Joe Palomo
wrote:
> > If you apply the ACL to the VLAN interface then you need to apply
the
> > ACL for egress (out) traffic to the server. Ingress (in) would deny
icmp
> > from server segment outbound. HTH.
> >
> > ccie16430 (Security)
> >
> > 2nd CCIE wrote:
> >
> >>Folks ;
> >> i have a trouble trying to do simple configuration on the 3550 .
> >> i have server connected to 3550 on port f0/11 .
> >>
> >> all i want to do is to deny the icmp to this server and allow
> everything
> >> else .
> >> although it looks something easy ..it does not work with me
> >>
> >> here is my configuration
> >>
> >> !
> >>interface FastEthernet0/11
> >> switchport access vlan 16
> >> switchport mode dynamic desirable
> >> ip access-group 101 in
> >>!
> >> !
> >>access-list 101 deny icmp any host 10.10.16.100
> >>access-list 101 permit ip any any
> >>!
> >>
> >> with this configuration ..i still can ping the server from anywhere
> ...i
> >> tried to apply the ACL on the interface vlan 16 ..nothing changed .
> >>
> >> if i remove the second entry of the ACL (basically deny everything
)
> ..it
> >> works
> >>
> >> but i need to the communication to the server ..only the ping i
want to
> >> disable ...
> >>
> >> what am i missing here ?
> >>
> >>
> >> thanks
> >>
> >>
> >>
> >>---------------------------------
> >>How low will we go? Check out Yahoo! Messengers low PC-to-Phone call
> >>rates.
> >>
> >>
> >>
> >>
> >
> >
> >
> > ---------------------------------
> > Get your email and more, right on the new Yahoo.com
>
>
This archive was generated by hypermail 2.1.4 : Sun Oct 01 2006 - 16:55:40 ART