Archive

Posts Tagged ‘SSL’

CiscoLive 2012 – Day 1

Day 1, for me, was on Saturday, when I arrived.  I’m grateful I was able to register that evening, seeing the lines this morning (Monday)!  Also, I was a little disappointed to see that the CiscoLive bag for this year was another backpack.  My one from last year is now in the trash, because it ripped in several places just from everyday use.  Oh well.

For most people, Day 1 was yesterday, Sunday.  For me, that was the “SSL VPN, AnyConnect and Secure Mobility” techtorial presented by Hakan Nohre (Consulting SE), John Eppich (Cisco Security and Mobility), Nadhem Al-Fardan (Solutions Architect), Ryan Wager (Cisco Security and Mobility) – all Cisco engineers.  This was an informative session, which will hopefully help me with the VPN exam I have tomorrow.  Though there was a lot to this session, here are a few of the highlights for me.

  1. Technically, SSL VPNs should be called TLS VPNs at this point, since that is the technology used for most VPNs.
  1. When configuring tunneling SSL VPNs, use DTLS when possible.  This is NOT the default (why not???)  The reason is that DTLS uses UDP packets for the tunnel, whereas TLS uses TCP.  That means that if an application’s TCP packet is dropped in transit, it will be retransmitted twice – once by the application and another time by the tunnel.  Also, voice traffic would be retransmitted by TLS, which is not desired.
  1. If you are doing VPN high-availability with multiple active ASAs, they recommended configuring “redirect-fqdn enable” in order to allow the Active Master to send the FQDN of the ASA to which the client is being redirected.  This way, the client doesn’t get a certificate error.  This solution depends on the DNS server allowing for Pointer records, or all ASAs having host to IP address configurations for the FQDNs of the other ASAs
  1. For the AnyConnect Server List in the AnyConnect Client Profile, do not put in the Host Address.  That way, the client avoids the certificate error when they connect or get a redirect.  Of course, the certificates used need to be created and installed appropriately.
  1. One thing that was clearly communicated was that client certificates are increasing in importance.  One piece of that is the use of Simple Certificate Enrollment Protocol (SCEP).  Note that anything that has “Simple” in the name probably isn’t.  In fact, the name is not consistently used.  If you are using Microsoft Certificate Services, they call it Network Device Enrollment Service (NDES).  And, of course, because I’m a network engineer, I think of “Network Device” as a switch or wireless LAN controller.  In this case, that’s not entirely true.  While those “network devices” are included, the term includes any device that needs to get a certificate.  So, that means client devices.  A good link for an explanation of NDES and its configuration can be found at http://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-ndes-in-active-directory-certificate-services-ad-cs-en-us.aspx

At the end of the day, I enjoyed meeting up with friends at a CiscoLive tweetup.  That brings up a couple things.  First, one of the big things of CiscoLive is meeting up with old friends and making new ones.  Some would even say that’s the real value.  The other point is that if you aren’t on Twitter, I recommend it.  Though I can’t always get on Twitter, there’s a lot of great people on it with helpful insights on a variety of technologies and situations.

Advertisements