Re: Guest Vlan Vs AUth-fail Vlan

Problem is in a scenario where we have guests/contractors and internal users
sharing desks:

What if the guest has an 802.1x supplicant which will obviously fail
authentication. He will get dumped into the Auth-fail vlan along internal
users and have access to remediation resources? Anyway to prevent this?

On Tue, Nov 2, 2010 at 8:56 AM, Sadiq Yakasai <sadiqtanko_at_gmail.com> wrote:

> Sorry, back again. :-)
>
> Need to add more information to that very last paragraph there.
>
> All that scenario is actually with MDA configured on the switchport. And in
> that last paragraph, when the client is authorized and the IP phone fails
> (dot1x or MAB), this causes a security violation on the switchport. Hence
> some more complications for you.
>
> Sadiq
>
> On Mon, Nov 1, 2010 at 7:13 PM, Sadiq Yakasai <sadiqtanko_at_gmail.com>
> wrote:
>
> > For the most part, true, all.
> >
> > You see, technically, MAB failures are just absence of the MAC address in
> > the ACS DB (or any other LDAP store, if configured on ACS). So the fact
> that
> > a RADIUS Reject comes back from the RADIUS server just means that MAC
> > address is unknown, hence a Guest VLAN. This applies to data or voice
> > devices that do not have supplicants on them.
> >
> > In the case of a dot1x enabled device and invalid credentials (with
> > supplicants, and hence dot1x case), a RADIUS Reject directly translates
> into
> > an AuthFail VLAN.
> >
> > Mark you though, today on Cisco switches, there is no support for Guest
> > VLAN on IP phones. The Guest and AuthFail VLANS all apply only to Data
> > devices and not IP phones. For example, when you have an IP phone and a
> PC
> > (plugged in behind the IP phone) both connected to the switch. The client
> > has a supplicant and the IP phone is doing MAB (which is my understanding
> of
> > your use case), then we have these possibilities:
> >
> > 1. IP phone passes and gets on the Voice VLAN (or domain). Client passes
> > and on the Data VLAN (or domain).
> >
> > 2. IP phone passes and client fails. IP phone gets treated like in #1 and
> > client gets placed into the AuthFail VLAN, if configured (similarly the
> > Guest VLAN for a MAB device). Otherwise re-attempt to authenticate the
> > client after 60 seconds by default - although we can tune a few things to
> > change behaviour here though.
> >
> > 3. IP phone and client behind it are connected together, the client
> passes
> > and IP phone fails. It gets abit nasty here you see. There is a race
> > condition because the client will make it to the network before the IP
> phone
> > (Cisco IP phone anyway, because of CDP and power uo delays, etc). The
> client
> > passes and gets placed into the data VLAN. When IP phone fails (MAB in
> this
> > case), it would be seeking to be placed into the Guest VLAN. This then
> means
> > you will have the Voice VLAN, the data VLAN (where the dot1x client is
> > already authorized) and the Guest VLAN all potentially needing to forward
> > traffic from the same physical port. Now, we cant do more than 2 VLANs on
> a
> > regular access ports today on Cisco switches, which is the issue.
> >
> > Hence there is no support for the Guest and AuthFail VLANs for IP phones
> > today. Hope that helps abit and not confuse you more. Let us know if you
> > need more info.
> >
> > Sadiq
> >
> >
> > On Mon, Nov 1, 2010 at 2:38 PM, Brian Landers <brian_at_bluecoat93.org
> >wrote:
> >
> >> On Mon, Nov 1, 2010 at 10:22 AM, GAURAV MADAN <
> gauravmadan1177_at_gmail.com
> >> >wrote:
> >>
> >> >
> >> > If my clients are non dot1x capable .. ( say VOIP ph etc ) . Hence I
> >> > intend to use MAB as authentication method ..
> >> >
> >> > What will be used ? Auth-fail vlan ?
> >> >
> >> >
> >> If you have MAB configured on an interface and the authentication fails,
> >> the
> >> port will be placed into the guest VLAN if it is configured. If no
> guest
> >> VLAN is configured, the port will be shutdown.
> >>
> >> The restricted/auth-fail VLAN is only used for clients that support
> 802.1x
> >> and fail an EAPoL login attempt.
> >>
> >>
> >> --
> >> Brian C Landers
> >> http://www.packetslave.com/
> >> CCIE #23115 (R&S + Security)
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > CCIEx2 (R&S|Sec) #19963
> >
>
>
>
> --
> CCIEx2 (R&S|Sec) #19963
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Nov 02 2010 - 11:48:18 ART