Help with Clean Access Architecture

Unanswered Question
Mar 1st, 2007

Hello All,

I wanted to engage some of the NetPros out there about designing our Clean Access architecture. We purchased 4 3140s (2 x CAMs w/ FO, 2 x CASs w/ FO). The goal is to use Clean Access to validate select areas of our head quarters, along with validate users in a remote location.

The HQ part of the design I can understand without issue. It's when we begin to deal with the remote office that I become uncertain about the design. The remote office is MPLS connected to HQ (L3 multi-hop). We want users in the remote office to also be L2 authenticate to the Clean Access cluster at HQ. Across MPLS this does not appear to be straightforward. We'd like to do a L2 deployment, but from what I've read this will require using L2TPv3 at the remote office to "tunnel" the VLANs from HQ to remote and vice-versa. My fear is that now the default gateway for the remote clients is the HQ Clean Access cluster. Therefore... all traffic will be "switched" across their WAN link. This becomes and issue as the remote office has local Windows domain controllers for faster file access on another VLAN... and in this scenario it sounds like the workstations would have to travel across the L2TPv3 tunnel to HQ to just have to go back across the tunnel to the remote office for file access. Sounds slow!

Does anyone have recommendations as to how to design this centralized, L2, OOB architecture. In my mind I would want the clients attempting authentication to the switch... switch forward to the CAS... CAS validates posture and passes down necessary VLAN to switch. All VLAN'ing and switching is kept remote. We operate all 3750 switches... so our infrastructure can work with NAC. Sorry for the long post, just wanted to try to explain the requirements. Thanks for the help.

-Mike

http://cs-mars.blogspot.com

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
pcomeaux Mon, 03/05/2007 - 14:43

Hi Mike -

Very good questions. You definitely do not need the L2TPv3 across the WAN to control the ports at the remote site.

The CASs can be deployed L2 In-Band (IB), L3 In-Band (IB), L2 Out-of-Band (OOB) or L3 Out-of-Band (OOB).

L3 OOB can be used to control the switches at the remote sites. A 2nd vlan is required for the remote site to serve as the authentication vlan. All ports start off on this Auth Vlan when a user plugs in.

The user receives an IP Address on this Auth Vlan and the local L3 device is the GWY. The L3 device should have ACLs to protect the rest of the network from this Auth Vlan. The only permit entries in the ACL should let the users get to CAS and the remediation servers. Using a network like 192.168.x.x and varying the 3rd octet on a per-site basis simplifies the ACLs if you are using the 10.x.x.x as your internal addressing. The ACLs should be places on all the MPLS routers to protect the production network from the Auth network.

Once the user proves trustworthy, the Clean Access changes the vlan on the switch to the production/normal vlan and the user has complete access as before.

CASs can be either one of the 4 roles (L2 IB, L3 IB, L2 OOB, L3 OOB) when they are added to the CAM.

If you plan to use L2 OOB for your HQ and L3 OOB for the remotes, you may need to add 1 more CAS pair to your architecture.

We have some great diagrams that the Clean Access product team have put together that will illustrate this architecture to you.

Your local SE / CSE should be able to provide this to you.

Let us know if you have any follow up questions.

Hope this helps.

peter

Actions

This Discussion