Should You Be Using Cisco AnyConnect?

It’s hard these days to keep on top if the latest and greatest when marketing keeps changing things. I think that’s why a lot of people are sometimes hesitant to migrate an existing deployment to a new version. I have heard more than once that “its the same old stuff in a different package.” That’s not true in the case of Cisco’s AnyConnect Secure Mobility Client v3.0. How so? Let’s look at a few points.

A Single Client For All Your Needs

The New AnyConnect client now packages multiple functions. In the past the Secure Services Client, CSSC was installed to provide enhanced authentication capabilities for wired and wireless networks. This is now part of the AnyConnect Solutions. It’s called the Network Access Manager.

Do you recall the Cisco NAC Client? It’s now packaged into AnyConnect and is called the AnyConnect Posture Module.

There’s also the Web Security Module and Telemetry Module.

All-in-all this client simplifies life with a one stop shop for Cisco Client installs.

Multiple OS Support

Windows, Mac, Linux, iOS devices… It’s pretty much available on the mainstream OS’s.

Cool Features

There are some cool features built into it like Trusted Network Detection, Always-On, Start-Before-Logon, and so on. You can configure these with ASDM and when the client connects it downloads any updates to the client profile. It makes it pretty simple to deploy.

IPsec Anyone?

AnyConnect 3.0 supports IKEv2, which means if you use an ASA running OS 8.4 you can use the any connect client for IPSec connectivity as well, further reducing the number of clients you have to deal with.

My Take

While there are a few things that bother me about the client, like the fact that Cisco Secure Desktop doesn’t launch if you connect in with the AnyConnect Client, but it will if you connect in via web launch, I would say it’s worth migrating to. I don’t think there is a large enough user base of Cisco Secure Desktop to make the little quirky “features” like that matter to most people.

How to Get Started

To get started with a migration you’ll need to upgrade to ASA 8.4. This may require a memory upgrade on your devices, but the features that are now available in the ASA make it worthwhile. Talk to your Cisco rep if you have any questions of course, and have fun with it. It’s not a perfect technology but it certainly has some cool capabilities.

AnyConnect 3.0 Client Profiles

The Cisco AnyConnect 3.0 Security Mobility Client has made some really neat changes. In doing some development recently I have had the opportunity to spend some time working with this version. I have to say that I do like it. But there are little gotcha’s that I figured I would share.

My Lab Topology is fairly simple. Basically I have a client on the outside and a server on the inside.

Acp1

I’m not so concerned with connecting to the server right now, but more so, I’m concerned with how I can centrally apply policy to my clients and then have them updated. To make the changes to the client, including company customization I am using the AnyConnect Profile Editor that’s embedded in ASDM. You can see the configuration page in the image below.
[Read more...]

Microsoft 2008 Server R2 CA Services for the Lose!

Frustration
For the last week I have been developing some content that revolves around SSL VPNs and the new ASA 8.4 version of code. Basically I wanted to configure a Microsoft CA Server so that I could enroll the ASA with it, assign the received certificate to the outside interface, and then create an SSL VPN to it.

After many attempts here is what I learned:

  • The New SCEP settings defaulted in Network Device Enrollment Services suck
  • Basically the certificate that is issued by default is not usable by the ASA for SSL authentication
  • Nobody has a good walk through of how to change the Server to make this work.
  • So, I decided it was my duty to come up with a solution. So, what did I do? I rolled it back to Windows Server 2003 and I haven’t looked back.

    Takeaway

    Microsoft has no idea how to integrate with a Cisco Network in a simple fashion. Since Cisco pushes the use of SSL for VPN I would either use Windows Server 2003 or stay away from Microsoft CA Services all together.

    Cisco ASA 8.4 and SCEP Proxy

    One of the new features of Cisco ASA 8.4 is the SCEP proxy capability.

    The SCEP proxy has two goals:

  • Provide automatic machine certificate deployment capability for VPN
  • Make it very difficult to establish VPN connections to corporate networks from
  • Essentially it allows the end user to enroll with an internal CA Server using SCEP, but without opening up the CA Server to external reachability. Here’s how the basic process works assuming the device is not yet enrolled with the CA Server:

    1. Cisco Secure Desktop will scan the machine and send the scan attributes to the ASA. The attribute that’s used is the unique identifier of a device. This attribute can be a part of the certificate and used to uniquely identify each device. It’s also noteworthy that you must have the ANyConnect Premium License to use the Machine ID for SCEP.
    2. Next, the ASA will request certificate authentication from the client. Authentication fails since there is no certificate yet. Provided the tunnel group is configured for SCEP enrollment, the ASA proceeds to do AAA, DAP and the SCEP enrollment.
    3. You can use double authentication but its not required. If you choose to use double authentication the concept would be to use User authentication as the primary authentication and the unique identifier as the secondary authentication. The ASA will pre-fill the secondary username with the machine unique-id that it gets from the CSD host scan.
    4. If you want to enforce restrictive policies on the connections that are trying to get a certificate prior to enrollment this can be done using DAP at this stage. ASA 8.4 added a new attribute, “aaa.cisco.sceprequired” to DAP that gets set to true if the connection fails the certificate authentication. If this attribute is toggled to true you could then configure your DAP policy to apply ACLs, web ACLs, and so on to the connection.
    5. Next the VPN connection establishes with the required ACL’s (received from DAP) applied to it. The client will not start key generation for SCEP until AAA authentication succeeds and a VPN connection is established.
    6. Next, the client is notified to start the enrollment. It will send the SCEP requests to the ASA over HTTPS. This is a PKCS#7 request carried inside the HTTPS session. The ASA will look-up the session with which the request is associated and authorizes the relay of the request to the CA if the session is configured in the group for enrollment.
    7. Once the CA responds, ASA will relay it back to the client. If enrollment is successful then the client will present a configurable message to the user and disconnect the session. The user can connect again with the certificate and at this point it’s normal VPN connectivity.

    Overall the process is pretty simple. There are a few caveats to be aware of, for example, if you use a LOCAL CA on the ASA this doesn’t work. The ASA itself doesnt support SCEP enrollment. Also, polling isn’t supported so the CA Server needs to automatically grant the request.

    Social Widgets powered by AB-WebLog.com.