A few weeks ago, I decided to upgrade my home workstation to accommodate GNS3 and VMWare.   This was mainly done so that I would have a performance-tuned workstation when studying IE’s workbook labs for my Security track.  I originally configured the machine to dual-boot Fedora v8.0 x86 and Micro2003.  After upgrading the machine from 2GB to 8GB of memory, I soon realized there were limitations for each operating system and that they couldn’t access the additional memory.  For my Fedora instance, all I had to do was run ‘yum install kernel-PAE’ and now my linux instance could utilize the entire 8GB.  When I start the machine up in Runlevel 3, Fedora only uses 500K of the memory so now the rest is free for emulating. 

My windows instance, however, was more of a challenge.  For those of you who are unaware, Micro2003 is just an nLite version of Windows 2003 Enterprise.  Reading through Microsoft’s data sheets reveals that 8GB is supported for the enterprise version.  Despite all the research and configuration changes I made (i.e. adding the /PAE switch to the boot.ini, changing the registry settings, or manually updating the ntoskrnl.exe file), I couldn’t get Micro2003 to recognize more than 3.5GB of memory.  In my attempts at isolating this memory problem, I formatted the drive and installed the full Windows 2003 Enterprise version which didn’t help my cause in any way because only 3.5GB was recognized.

I was a little frustrated at this point and started Googling around for alternative operating systems.  Then I stumbled upon, Damn Tiny Vista, and decided to install it.  Whoever created this nLite version of Vista left the ability to connect/disconnect to CIFS shares, which is a huge plus since Micro2003 didn’t support it.  Now the full 8GB is recognized and useable.  After a few hours of playing around with the OS, I decided to test out the OS and attempted to conduct some work through a VPN session.  I connected into our WEBVPN portal and Cisco’s AnyConnect VPN Client version 2.2.0133 installed without any issues.

The firewall bundle we use for our portal came with 750 client licenses and 2 WEBVPN licenses.  The popularity for WEBVPN access has increased and so now I find myself fighting to even use it.  On occasion, I’ve reverted back to using the actual client.  The problem now is Cisco’s VPN Client is not supported on 64-bit operating systems nor do they have plans for upgrading.  Their primary focus is to develop AnyConnect, so I was left with finding another client software solution.  I found NCP Secure and it is supported in Vista.  Installing was the application was straight forward.

The only real issue I had with the software was that it couldn’t import my .pcf files as stated, so I had to configure my connections manually.

For those that are interested in the actual configuration, here’s what my ASA looks like:

ip local pool EZVPN-Pool 10.2.2.217-10.2.2.223 mask 255.255.255.248

crypto ipsec transform-set EZVPNSET esp-3des esp-md5-hmac

crypto dynamic-map EZVPNDYN 20 set transform-set EZVPNSET
crypto dynamic-map EZVPNDYN 20 set security-association lifetime seconds 28800
crypto dynamic-map EZVPNDYN 20 set security-association lifetime kilobytes 4608000
crypto dynamic-map EZVPNDYN 20 set reverse-route
crypto map secure 20 ipsec-isakmp dynamic EZVPNDYN

crypto map secure interface outside

crypto isakmp identity address
crypto isakmp enable outside

crypto isakmp policy 20
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400

tunnel-group EZVPN type remote-access
tunnel-group EZVPN general-attributes
address-pool EZVPN-Pool
default-group-policy EZVPN

tunnel-group EZVPN ipsec-attributes
pre-shared-key TEST

And here’s what my NCP configuration looks like:

Basic Settings:
-Profile Name: WORK_VPN
-Communication Medium: LAN (over IP)

Line Management:
-Connection Mode: manual
-Inactivity Timeout (sec): 3600

IPSec General Settings:
-Gateway (Tunnel Endpoint): 194.4.4.44
-Policies:
–IKE Policy: PSK-3DES-MD5-DH2
–IPSec Policy: ESP-3DES-MD5
–Exch. Mode: Aggressive Mode
–PFS Group: none
–Policy Lifetimes:
—IKE Policy
—-Duration: 000:08:00:00
—IPSec Policy
—-Life Type: both
—-Duration: 000:08:00:00
—-kBytes: 4608000

Advanced IPSec Options:
-IPSec Compression

Identities:
-Local Identity:
–IKE ID-Typ: Free string used to identify groups
–IKE ID: EZVPN
-Pre-shared Key
–Shared Secret: TEST
–Confirm Secret: TEST
–Certificate Configuration: none
-Extended Authentication (XAUTH)
–User ID: netops
–Password: OCSIC
–from the configuration above

IP Address Assignment:
-Assignment of the Private Address: IKE config mode
-IP Address: 0.0.0.0

Link Firewall:
-Stateful Inspection: off

The key to getting this client software to connect to the firewall gateway succesfully is verifying all your settings.  If you run into any connection issues, my suggestion would be to use the Log>Logbook feature to review your logs or if you have a backdoor into your firewall (tsk tsk), you could run ‘debug crypto isakmp sa’ to help narrow down the issue.

Last Thursday, we celebrated Thanksgiving here in the US.  Aside from feasting on turkey and watching football all day, I celebrated my 1st year anniversary as an IE by studying up on the WEBVPN technology.  Before I begin, let me just say that the past 365 days since obtaining my number has been a great experience.  Having my digits opened so many consulting doors which allowed me exposure to many new environments and technologies.  Just thinking about another success story now makes me anxious and eager to finish up my Security track.  BTW, originally I had my Security lab scheduled for 12/10/2008, but a side contract had kept me quite busy forcing me to reschedule for 2009.  I’m now planning on taking the lab on 02/27/2009 at the San Jose location.  Worst case scenario is if I blow the attempt, I have another shot before the v3.0 changes come in affect.

In the past, I’ve implemented WEBVPN successfully on various devices such as the concentrator, router, and firewall.  Over the long weekend, I manage to lab up a few work-related scenarios.  I say work-related because shortly before the Thanksgiving holiday began, I was asked to allow Active Directory authentication through our WEBVPN portal.  I had configured NTLM authentication on the firewall which worked great, but now I needed to tie in a 2nd domain owned by a different group.  For the sake of this posting, just assume the authentication portion is working.  I promise to write more about it another time.

To properly test the WEBVPN authentication, I needed access to a Windows machine  Since there only a handful Apple and linux users, it made sense to test everything in a Windows environment.  Most all of my machines at home have been converted to linux; there are only 2 laptops left that are running MK3.  During my testing I was able to authenticate properly off the WEBVPN portal, but the sslclient package installation kept failing and wouldn’t produce any errors in the log.  I immediately started googling for dlls that may be missing in MK3 that would allow AnyConnect to install properly.  At first I couldn’t quite find anything that made sense, then I stumbled upon a forum article that talked about applications that used the “Smart Card” service for security.  The problem with MK3 or most nLite installations is people seem to remove the service completely.

To install the “Smart Card” service in MK3 or any nLite version, follow these steps:

1) Copy the following dlls from a working server with Windows 2003 Service Pack 2 to the C:\Windows\System32 subdirectory:

softpub.dll
wintrust.dll
dssenh.dll
rsaenh.dll
gpkcsp.dll
sccbase.dll
slbcsp.dll
mssip32.dll
cryptdlg.dll
initpki.dll

2) Open the registry and export the key to SCardSvr.reg:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SCardSvr

3) In your MK3 or nLite installation, import the SCardSvr.reg key

4) Reboot the machine and start the service

Once the service has been installed and is running, the sslcient installation can complete.  Searching for information for each of the dlls reveals that the last 3 contain the necessary security libraries that applications are referencing.  Aside from fixing AnyConnect package installation, it appears this exact dll list allows iTunes version 8.0.2.20 to run as well.

Recently, I was asked to allow linux client workstations access into our network via WEBVPN running on our ASA.  As of this writing, the only AnyConnect versions available on Cisco’s website for download were version 2.2.0133.  The only dependency that is required for the linux version of AnyConnect is the Java Runtime Environment.  Connecting to the WEBVPN with a Fedora v8 workstation was flawless (as it should be). The AnyConnect client installed without any errors and I was able to authenticate into our network.

Unfortunately, the behaviour was quite different when connecting with a Fedora v9 workstation. The AnyConnect client installed properly, but when it came time to authenticate my credentials, I encountered this error message:

The error is a bit misleading and doesn’t even relate to the actual problem — AnyConnect is unable to use the Network Security Service libraries. Googling around lead me to a few fixes for Ubuntu, but not for Fedora. The steps to correct the problem in Ubuntu are as follows:

ln -s /usr/lib/libnss3.so.1d /usr/lib/libnss3.so
ln -s /usr/lib/libplc4.so.0d /usr/lib/libplc4.so
ln -s /usr/lib/libnspr4.so.0d /usr/lib/libnspr4.so
ln -s /usr/lib/libsmime3.so.1d /usr/lib/libsmime3.so

In Fedora v9, the libraries are actually stored in a different directory.  Here’s the correct path to link your libraries:

ln -s /lib/libnss3.so /usr/lib
ln -s /lib/libnspr4.so /usr/lib
ln -s /lib/libplc4.so /usr/lib
ln -s /lib/libsmime3.so /usr/lib

Cisco has already identified this as a bug, CSCso89871, and plans on having the scripts corrected for the next version of AnyConnect.