ASA REMOTE ACCESS VPN, ANYCONNECT

Su an desteklenmeyen ama eski versiyonlarda desteklenmeyen

Remote Access VPN

Cisco ASA Remote Access VPN

In this lesson we’ll take a look how to configure remote access IPsec VPN using the Cisco VPN client. This allows remote users to connect to the ASA and access the remote network through an IPsec encrypted tunnel.
The remote user requires the Cisco VPN client software on his/her computer, once the connection is established the user will receive a private IP address from the ASA and has access to the network.
The Cisco VPN client is end-of-life and has been replaced by the Cisco Anyconnect Secure Mobility Client. It’s not supported any more but still widely in use nowadays.
This is the topology that we will use for this example:

The ASA has two interfaces: inside and outside. Imagine the outside interface is connected to the Internet where a remote user wants to connect to the ASA. On the inside we find R1, I will only use this router so the remote user has something to connect to on the inside network. Let’s look at the configuration!

Configuration

VPN Pool

First we will configure a pool with IP addresses that we will assign to remote VPN users:

ASA1(config)# ip local pool VPN_POOL 192.168.10.100-192.168.10.200

I will use IP address 192.168.10.100 – 192.168.10.200 for our VPN users. We need to tell the ASA that we will use this local pool for remote VPN users:

ASA1(config)# vpn-addr-assign local

This is done with the vpn-addr-assign command.

NAT Exemption

If you have NAT enabled on the ASA then we need to make sure that traffic between 192.168.1.0 /24 (the local network) and 192.168.10.0 /24 (our remote VPN users) doesn’t get translated. To accomplish this we will configure NAT excemption. The example below is for ASA version 8.3 or higher:

ASA1(config)# object network LAN  
ASA1(config-network-object)# subnet 192.168.1.0 255.255.255.0

ASA1(config)# object network VPN_POOL
ASA1(config-network-object)# subnet 192.168.10.0 255.255.255.0

ASA1(config)# nat (INSIDE,OUTSIDE) source static LAN LAN destination static VPN_POOL VPN_POOL

We create two network objects, one for our local network and another one for the remote VPN users. The NAT rule tells the ASA not to translate traffic between the two networks.

Group Policy

When the remote user has established the VPN, he or she will be unable to access anything on the Internet…only the remote network is reachable. For security reasons this is a good practice as it forces you to send all traffic through the ASA. If you don’t want this then you can enable split tunneling. With split tunneling enabled, we will use the VPN only for access to the remote network. Here’s how to enable it:

ASA1(config)# access-list SPLIT_TUNNEL standard permit 192.168.1.0 255.255.255.0

Now we can create a group policy. This allows you to assign different remote users to different groups with different attributes. You might want to have a group policy for “network engineers” and another one for “regular users” each with different DNS servers, timeout settings, etc. Here’s an example:

ASA1(config)# group-policy VPN_POLICY internal
ASA1(config)# group-policy VPN_POLICY attributes
ASA1(config-group-policy)# dns-server value 8.8.8.8
ASA1(config-group-policy)# vpn-idle-timeout 15
ASA1(config-group-policy)# split-tunnel-policy tunnelspecified
ASA1(config-group-policy)# split-tunnel-network-list value SPLIT_TUNNEL

The group policy is called VPN_POLICY and it’s an internal group policy which means it is created locally on the ASA. You can also specify an external group policy on a RADIUS server. I added some attributes, for example a DNS server and an idle timeout (15 minutes). Split tunneling is optional but I added it to show you how to use it, it refers to the access-list we created earlier.
If you want to configure an access-list so the remote VPN users can only reach certain networks, IP addresses or ports then you can apply this under the group policy.
Let’s continue and create a user for remote access:

Username

ASA1(config)# username VPN_USER password MY_PASSWORD

We configured a group policy and user but we haven’t configured any IPsec settings yet. Let’s configure phase 1…

IPsec Phase 1

ASA1(config)# crypto ikev1 policy 10
ASA1(config-ikev1-policy)# encryption aes
ASA1(config-ikev1-policy)# hash sha
ASA1(config-ikev1-policy)# authentication pre-share 
ASA1(config-ikev1-policy)# group 2
ASA1(config-ikev1-policy)# lifetime 86400

This is just a basic example. We will use AES for encryption, SHA for integrity, a pre-shared key and Diffie-Hellman group 2 for key exchange. The lifetime before we have to do a renegotiation is 86400 seconds. Let’s enable this IKEv1 policy on the outside interface:

ASA1(config)# crypto ikev1 enable OUTSIDE
ASA1(config)# crypto isakmp identity address

And we can continue with phase 2:

IPsec Phase 2

ASA1(config)# crypto ipsec ikev1 transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac

We will configure a transform set called “MY_TRANSFORM_SET” and we use ESP with AES/SHA. The next step is to configure a crypto map, this has to be a dynamic crypto map since the remote VPN users probably are behind dynamic IP addresses and we don’t know which ones:

ASA1(config)# crypto dynamic-map MY_DYNA_MAP 10 set ikev1 transform-set MY_TRANSFORM_SET

The dynamic crypto map is called “MY_DYNA_MAP” and it refers to the transform set. Even though we have a dynamic crypto map, we still have to attach this to a static crypto map like this:

ASA1(config)# crypto map MY_CRYPTO_MAP 10 ipsec-isakmp dynamic MY_DYNA_MAP

And attach it to the outside interface:

ASA1(config)# crypto map MY_CRYPTO_MAP interface OUTSIDE

Tunnel Group

The last step is to create a tunnel group. This binds the group policy and pool together and it’s where we configure a pre-shared key for the group policy:

ASA1(config)# tunnel-group MY_TUNNEL type remote-access 
ASA1(config)# tunnel-group MY_TUNNEL general-attributes 
ASA1(config-tunnel-general)# address-pool VPN_POOL
ASA1(config-tunnel-general)# default-group-policy VPN_POLICY

The tunnel group is called “MY_TUNNEL” and we add the pool and group policy. Now we can configure its attributes:

ASA1(config)# tunnel-group MY_TUNNEL ipsec-attributes 
ASA1(config-tunnel-ipsec)# ikev1 pre-shared-key MY_SHARED_KEY

We’ll set the pre-shared key to “MY_SHARED_KEY”.
That’s all we have to do on the ASA, let’s look at the client now…

Verification

After installing the VPN client and starting it, you will see the following screen:

Click on New and you will see the following screen:

There are a couple of fields we have to enter here:

• Connection Entry and Description: Fill in whatever you like, these are only used as a general description of the connection.
• Host: This is the outside IP address of the ASA.
• Name: Enter the tunnel group name here, in our example “MY_TUNNEL”.
• Password: This is the pre-shared key under the tunnel group, not the user password! In our example this is “MY_SHARED_KEY”.

Click Save to save your settings to get back to the main screen:

Hit the Connect button and you should get a pop-up that requests the user credentials:

Now you can enter the username and password that we created. Click on OK and you should get connected and see this:

In the bottom of the VPN client you will see that it is connected…excellent!
We are connected but it’s good practice to check a couple of things, first let’s see what IP address we received:

C:UsersVPN-PC>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : VPN-PC
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection 2:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Cisco Systems VPN Adapter for 64-bit Windows
   Physical Address. . . . . . . . . : 00-05-9A-3C-78-00
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::2815:c8ae:486:fade%20(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.10.100(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 419431834
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-17-FF-B9-9F-00-0C-29-E7-0F-2E
   DNS Servers . . . . . . . . . . . : 8.8.8.8
   NetBIOS over Tcpip. . . . . . . . : Enabled

You can see the VPN client created an additional interface and it has received an IP address from the VPN pool. So far so good, let’s see if we have connectivity…I’ll send a ping to R1:

C:UsersVPN-PC>ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=2ms TTL=255
Reply from 192.168.1.1: bytes=32 time=1ms TTL=255
Reply from 192.168.1.1: bytes=32 time=1ms TTL=255
Reply from 192.168.1.1: bytes=32 time=10ms TTL=255

Ping statistics for 192.168.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 10ms, Average = 3ms

Our remote VPN user is able to reach R1, let’s see what the ASA thinks of this:

ASA1# show crypto ipsec sa
interface: OUTSIDE
    Crypto map tag: MY_DYNA_MAP, seq num: 10, local addr: 10.10.10.1

      local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.10.100/255.255.255.255/0/0)
      current_peer: 10.10.10.2, username: VPN_USER
      dynamic allocated peer ip: 192.168.10.100
      dynamic allocated peer ip(ipv6): 0.0.0.0

      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 4, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #TFC rcvd: 0, #TFC sent: 0
      #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
      #send errors: 0, #recv errors: 0

      local crypto endpt.: 10.10.10.1/0, remote crypto endpt.: 10.10.10.2/0
      path mtu 1500, ipsec overhead 74(44), media mtu 1500
      PMTU time remaining (sec): 0, DF policy: copy-df
      ICMP error validation: disabled, TFC packets: disabled
      current outbound spi: D7E67C68
      current inbound spi : CEB125F9
              
    inbound esp sas:
      spi: 0xCEB125F9 (3467716089)
         transform: esp-aes esp-sha-hmac no compression 
         in use settings ={RA, Tunnel, IKEv1, }
         slot: 0, conn_id: 4096, crypto-map: MY_DYNA_MAP
         sa timing: remaining key lifetime (sec): 28558
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x0000001F
    outbound esp sas:
      spi: 0xD7E67C68 (3622206568)
         transform: esp-aes esp-sha-hmac no compression 
         in use settings ={RA, Tunnel, IKEv1, }
         slot: 0, conn_id: 4096, crypto-map: MY_DYNA_MAP
         sa timing: remaining key lifetime (sec): 28558
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap: 
          0x00000000 0x00000001

ASA;

hostname ciscoasa
!
ip local pool VPN_POOL 192.168.10.100-192.168.10.200
!
interface FastEthernet0/0
 nameif INSIDE
 security-level 100
 ip address 192.168.1.254 255.255.255.0 
!             
interface FastEthernet0/1
 nameif OUTSIDE
 security-level 0
 ip address dhcp setroute 
!
object network LAN
 subnet 192.168.1.0 255.255.255.0
object network VPN_POOL
 subnet 192.168.10.0 255.255.255.0
access-list SPLIT_TUNNEL standard permit 192.168.1.0 255.255.255.0 
!
nat (INSIDE,OUTSIDE) source static LAN LAN destination static VPN_POOL VPN_POOL
!
crypto ipsec ikev1 transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac 
crypto ipsec security-association pmtu-aging infinite
crypto dynamic-map MY_DYNA_MAP 10 set ikev1 transform-set MY_TRANSFORM_SET
crypto map MY_CRYPTO_MAP 10 ipsec-isakmp dynamic MY_DYNA_MAP
crypto map MY_CRYPTO_MAP interface OUTSIDE
!
crypto isakmp identity address 
crypto ikev1 enable OUTSIDE
crypto ikev1 policy 10
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400
crypto ikev1 policy 65535
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
!
group-policy VPN_POLICY internal
group-policy VPN_POLICY attributes
 dns-server value 8.8.8.8
 vpn-idle-timeout 15
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SPLIT_TUNNEL
dynamic-access-policy-record DfltAccessPolicy
username VPN_USER password E5PbZWWQ.j3bJJHz encrypted
tunnel-group MY_TUNNEL type remote-access
tunnel-group MY_TUNNEL general-attributes
 address-pool VPN_POOL
 default-group-policy VPN_POLICY
tunnel-group MY_TUNNEL ipsec-attributes
 ikev1 pre-shared-key *****
!
class-map inspection_default
 match default-inspection-traffic          
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect ip-options 
  inspect netbios 
  inspect rtsp 
  inspect sunrpc 
  inspect tftp 
  inspect xdmcp 
  inspect dns preset_dns_map 
  inspect ftp 
  inspect h323 h225 
  inspect h323 ras 
  inspect rsh 
  inspect esmtp 
  inspect sqlnet 
  inspect sip  
  inspect skinny  
policy-map type inspect dns migrated_dns_map_1
 parameters
  message-length maximum client auto
  message-length maximum 512
!
service-policy global_policy global
!
: end 

Cisco ASA Anyconnect Remote Access VPN

https://www.cisco.com/c/en/us/products/collateral/security/asa-5500-series-next-generation-firewalls/prod_brochure0900aecd80402e39.html

In this lesson we will see how you can use the anyconnect client for remote access VPN. Anyconnect is the replacement for the old Cisco VPN client and supports SSL and IKEv2 IPsec. When it comes to SSL, the ASA offers two SSL VPN modes:

• Clientless WebVPN
• AnyConnect VPN

The clientless WebVPN method does not require a VPN client to be installed on the user’s computer. You just open your web browser, enter the IP address of the ASA and you will get access through a web portal. You only have limited access to a number of applications, for example:

• Internal websites (HTTP and HTTPS)
• Web applications
• Windows file shares
• Email servers (POP3, IMAP, SMTP)
• Microsoft Outlook Web Access

There is no full network access when you use clientless WebVPN.
Anyconnect VPN offers full network access. The remote user will use the anyconnect client to connect to the ASA and will receive an IP address from a VPN pool, allowing full access to the network.
In this lesson we will use clientless WebVPN only for the installation of the anyconnect VPN client. The remote user will open a web browser, enters the IP address of the ASA and then it will automatically download the anyconnect VPN client and establishes the connection. Here’s the topology that we will use:

Above we have the ASA firewall with two security zones: inside and outside. The remote user is located somewhere on the outside and wants remote access with the Anyconnect VPN client. R1 on the left side will only be used so that we can test if the remote user has access to the network. Let’s take a look at the configuration!

ASA Configuration

The remote user will be able to download the anyconnect VPN client from the ASA so we need to store it somewhere. Each operating system has a different installation file and we need to have them on the flash memory of the ASA:

ASA1# show flash: 
--#--  --length--  -----date/time------  path
   10  8192        Dec 02 2014 19:09:34  log
   18  8192        Dec 02 2014 19:09:44  crypto_archive
  106  25088760    Aug 04 2014 13:59:20  asdm-731.bin
  109  27113472    Aug 25 2014 13:10:56  asa915-k8.bin
  112  31522773    Aug 09 2014 15:01:52  anyconnect-win-3.1.03103-k9.pkg
  113  9993060     Aug 09 2014 15:06:50  anyconnect-linux-3.1.03103-k9.pkg
  114  11293375    Aug 09 2014 15:08:34  anyconnect-macosx-i386-3.1.03103-k9.pkg

255426560 bytes total (149487616 bytes free)

https://software.cisco.com/download/home/286281283/type/282364313/release/4.6.01103 

anyconnect-win-4.6.01103-webdeploy-k9.pkg

There is a different PKG file for each operating system. Above you can see that I have one for Windows, Linux and Mac OS X. If you don’t have them already, make sure you copy them to the flash memory of the ASA.
Our next step is to enable clientless WebVPN:

ASA1(config)# webvpn
 
Now we specify which anyconnect PKG files we want to use:

ASA1(config-webvpn)# anyconnect image flash:/anyconnect-win-3.1.03103-k9.pkg
 
I’m only specifying the anyconnect client for Windows but if you want to support Linux or Mac OS X users, make sure to add them here. Now we can enable client WebVPN on the outside interface:

ASA1(config-webvpn)# enable outside 
INFO: WebVPN and DTLS are enabled on 'OUTSIDE'.
 
This enables WebVPN on the outside interface. We also need to enable anyconnect:

ASA1(config-webvpn)# anyconnect enable
 
When you have an inbound access-list on the outside interface then all your decrypted traffic from the SSL WebVPN has to match the inbound access-list. You can either create some permit statements for the decrypted traffic or you can just tell the ASA to let this traffic bypass the access-list:

ASA1(config)# sysopt connection permit-vpn
 
When remote users connect to our WebVPN they have to use HTTPS. The following option is not required but useful, whenever someone accesses the ASA through HTTP then they will be redirected to HTTPS:

ASA1(config)# http redirect OUTSIDE 80
 
The ASA will assign IP addresses to all remote users that connect with the anyconnect VPN client. We’ll configure a pool with IP addresses for this:

ASA1(config)# ip local pool VPN_POOL 192.168.10.100-192.168.10.200 mask 255.255.255.0
 
Remote users will get an IP address from the pool above, we’ll use IP address range 192.168.10.100 – 200.
By default all traffic will be sent through the tunnel once the remote user is connected. If you want to allow remote users to access the Internet once they are connected then you need to configure split tunneling. We will configure an access-list that specifies what networks we want to reach through the tunnel:

ASA1(config)# access-list SPLIT_TUNNEL standard permit 192.168.1.0 255.255.255.0
 
This means that the SSL VPN tunnel will only be used to reach the 192.168.1.0 /24 network. Now we can configure the anyconnect group policy:

ASA1(config)# group-policy ANYCONNECT_POLICY internal
ASA1(config)# group-policy ANYCONNECT_POLICY attributes
ASA1(config-group-policy)# vpn-tunnel-protocol ssl-client ssl-clientless 
ASA1(config-group-policy)# split-tunnel-policy tunnelspecified
ASA1(config-group-policy)# split-tunnel-network-list value SPLIT_TUNNEL
ASA1(config-group-policy)# dns-server value 8.8.8.8
ASA1(config-group-policy)# webvpn
ASA1(config-group-webvpn)# anyconnect keep-installer installed
ASA1(config-group-webvpn)# anyconnect ask none default anyconnect
ASA1(config-group-webvpn)# anyconnect dpd-interval client 30

There’s quite some stuff in the group policy, let me break it down for you:

• The group policy is called “ANYCONNECT_POLICY” and it’s an internal group policy which means that we configure it locally on the ASA. An external group policy could be on a RADIUS server.
• The VPN tunnel protocol is ssl-client (for anyconnect) and also ssl-clientless (clientless SSL VPN).
• Split tunneling has been enabled and we refer to the access-list “SPLIT_TUNNEL” that we just created.
• The DNS server 8.8.8.8 will be assigned to remote VPN users.
• Normally when the remote VPN user terminates the session, the anyconnect installer will be uninstalled. The anyconnect keep-installer installed command leaves it installed on the user’s computer.
• The anyconnect ask command specifies how the anyconnect client will be installed on the user’s computer. The none default anyconnect part tells the ASA not to ask the user if he/she wants to use WebVPN or anyconnect but just starts the download of the anyconnect client automatically.
• The anyconnect dpd-interval command is used for Dead Peer Detection. The remote user’s anyconnect client will check every 30 seconds if the ASA is still responding or not. You can also use dpd-interval gateway so that the ASA checks if the remote user is still responding.

After the group policy configuration we have to create a tunnel group which binds the group policy and VPN pool together:

ASA1(config)# tunnel-group MY_TUNNEL type remote-access 
ASA1(config)# tunnel-group MY_TUNNEL general-attributes 
ASA1(config-tunnel-general)# default-group-policy ANYCONNECT_POLICY
ASA1(config-tunnel-general)# address-pool VPN_POOL
ASA1(config-tunnel-general)# exit

When the remote user connects, the ASA will show a group name to the remote user, we can specify the group name like this:

ASA1(config)# tunnel-group MY_TUNNEL webvpn-attributes 
ASA1(config-tunnel-webvpn)# group-alias SSL_USERS enable
 
You will see that when the remote user connects, the ASA will show the group name “SSL_USERS”. If you have multiple tunnel groups then your remote users should be able to select a certain tunnel group:

ASA1(config)# webvpn 
ASA1(config-webvpn)# tunnel-group-list enable 
 
Now we can create a user account:

ASA1(config)# username SSL_USER password MY_PASSWORD
 
We need to tell the ASA that this user account is allowed to access the network:

ASA1(config)# username SSL_USER attributes 
ASA1(config-username)# service-type remote-access
 
Everything is now in place on the ASA. We can use the client to connect to the ASA and install the anyconnect client.

Client Configuration

I will use a Windows 7 client with Internet Explorer for this. Start the browser and enter the IP address of the ASA as the URL. If you use HTTP, you will be redirected to HTTPS:

The ASA is using a self-signed certificate that is not recognized by the browser so that’s why you see this error. Click continue and you will see the following screen:

Now you can authenticate yourself. Enter the username and password that we created earlier. The group name is the group alias that we created. Once you are authenticated you will see this:

The client tries to download the Anyconnect automatically, this is because of the anyconnect ask none default anyconnect command that we used. Since we are using a self-signed certificate you will get the following error message:

You need to click on the Change Setting button and you will see this:

Click on the Apply Change button and you will see this:

Click on the retry the connection link and you will see this:

We get one more warning that the certificate cannot be verified. Click on Connect Anyway and the download will finally start:

Once it is completed you will see this:

The Anyconnect client has been installed and the connection has been established. If you look in the Windows taskbar then you will find a small icon:

Click on it and it will open the Anyconnect client, here’s what it looks like:

It is connected and if you want to see some details you need to click on the little “gear” icon, it will give you a nice overview of the connection:

This shows you the IP address that the client has received and some statistics about how much bytes were sent/received. This is looking good but it’s important to verify a couple of things before we end this lesson…

We got a lot of messages about the self-signed certificate that is untrusted. For this example it doesn’t matter but in a production network it might be a good idea to fix this problem. In another lesson I will show you how to use certificates that are trusted by your user’s browser.

Verification

Client Verification

First we’ll generate some traffic on the client, see if it can reach R1 on the inside network:

C:UsersVPN>ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=2ms TTL=255
Reply from 192.168.1.1: bytes=32 time=2ms TTL=255
Reply from 192.168.1.1: bytes=32 time=2ms TTL=255
Reply from 192.168.1.1: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms

C:UsersVPN>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : VPN-PC
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection 3:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64
   Physical Address. . . . . . . . . : 00-05-9A-3C-7A-00
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.10.100(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 8.8.8.8
   NetBIOS over Tcpip. . . . . . . . : Enabled 

ASA Verification

Everything on the client was looking good, there’s also a useful command on the ASA to verify our work:

ASA1# show vpn-sessiondb anyconnect 

Session Type: AnyConnect

Username     : SSL_USER               Index        : 6
Assigned IP  : 192.168.10.100         Public IP    : 10.10.10.2
Protocol     : Clientless SSL-Tunnel DTLS-Tunnel
License      : AnyConnect Premium
Encryption   : Clientless: (1)RC4  SSL-Tunnel: (1)RC4  DTLS-Tunnel: (1)AES128
Hashing      : Clientless: (1)SHA1  SSL-Tunnel: (1)SHA1  DTLS-Tunnel: (1)SHA1
Bytes Tx     : 6252805                Bytes Rx     : 133830
Group Policy : ANYCONNECT_POLICY      Tunnel Group : MY_TUNNEL
Login Time   : 16:30:35 UTC Tue Dec 9 2014
Duration     : 0h:11m:28s
Inactivity   : 0h:00m:00s
NAC Result   : Unknown
VLAN Mapping : N/A                    VLAN         : none

Cisco ASA Anyconnect Self Signed Certificate

By default the Cisco ASA firewall has a self signed certificate that is regenerated every time you reboot it. This can be an issue when you are using SSL VPN as the web browser of your user will give a warning every time it sees an untrusted certificate. In another lesson where I explained how to configure anyconnect remote access VPN you can see these errors when the remote users connects to the ASA. To fix this problem we have two options:

• Purchase and install an SSL certificate on the ASA from a trusted CA.
• Generate a self signed SSL certificate on the ASA and export it to your user’s computer.

The first option is the best one, you buy an SSL certificate from a provider like Verisign, Entrust, Godaddy, etc. and install it on the ASA. Web browsers have a lot of pre-installed root CA certificates from these providers so when you get a SSL certificate from them, your browser will show them as trusted. This is great because you don’t have to do anything on the user’s computer.
If you don’t want to buy a SSL certificate then we can use the second option. We will generate a SSL certificate on the ASA and self-sign it. This certificate is permanent so it doesn’t dissapear when you reboot the ASA, the problem however is that you have to export and import this certificate on each of your remote users’ computers.
That’s what we will do in this lesson…we will generate the SSL certificate, self-sign it and then export and import it on a remote user’s computer. This is the topology I will use:

The ASA is connected to a remote user on its outside interface. The user’s computer will run Windows 7. Let’s get started shall we?

ASA Configuration

There are a number of requirements when we work with certificates. First of all we need to configure the correct time, date, assign a hostname and domain name:

ciscoasa(config)# clock set 13:48:00 10 Dec 2014

The clock command will work but using NTP to keep your time synchronized would be better. Let’s configure a hostname:

ciscoasa(config)# hostname ASA1 

I’ll call my device “ASA1”. Now we configure a domain name:

ASA1(config)# domain-name NETWORKLESSONS.LOCAL

In PKI (Public Key Infrastructure) we need to have keys…a public and private key. When we generate a RSA key it will automatically generate these two keys. The public key can be shared with anyone and is used to encrypt or sign messages. Here’s how to generate the keys:

ASA1(config)# crypto key generate rsa label MY_RSA_KEY modulus 1024
INFO: The name for the keys will be: MY_RSA_KEY
Keypair generation process begin. Please wait...

 The key pair is called “MY_RSA_KEY”. You can see them here:

ASA1(config)# show crypto key mypubkey rsa | begin MY_RSA_KEY
Key name: MY_RSA_KEY
 Usage: General Purpose Key
 Modulus Size (bits): 1024
 Key Data:

  30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00ac99a2 
  2fc2907a 1e86ddf4 503dc102 72611d80 77ed5762 a857b297 ee609520 469c2dbe 
  f50c5ce1 ac39cba1 998f9504 93f8bfbd ddfaadf7 0cc1f322 f20a24b0 db7fd9e5 
  61a024d1 9f6f5380 562e7848 017e0f88 167732c5 aef50f80 e6431420 0745b9f4 
  9217f9df 31ca5a2f 05fe6af6 efb388d4 24a22355 7112458f c20f022f 7f020301 
  0001

We now have to create a “trustpoint”. The trustpoint is a container 
where certificates are stored. This is where we configure parameters 
like the FQDN, subject name, keypair, etc:  

 ASA1(config)# crypto ca trustpoint SELF_TRUSTPOINT
ASA1(config-ca-trustpoint)# enrollment self
ASA1(config-ca-trustpoint)# fqdn ASA1.NETWORKLESSONS.LOCAL
ASA1(config-ca-trustpoint)# subject-name CN=ASA1.NETWORKLESSONS.LOCAL
ASA1(config-ca-trustpoint)# keypair MY_RSA_KEY

 The trustpoint is called “SELF_TRUSTPOINT” and the enrollment self
 command means that the ASA will sign its own certificates. The 
certificate will be assigned to ASA1.NETWORKLESSONS.LOCAL. We will use 
the RSA keypair that we just generated. We can now enroll the actual 
certificate

 ASA1(config)# crypto ca enroll SELF_TRUSTPOINT

% The fully-qualified domain name in the certificate will be: ASA1.NETWORKLESSONS.LOCAL

% Include the device serial number in the subject name? [yes/no]: no

Generate Self-Signed Certificate? [yes/no]: yes

 ASA1(config)# show crypto ca certificates 
Certificate
  Status: Available
  Certificate Serial Number: 370d8754
  Certificate Usage: General Purpose
  Public Key Type: RSA (1024 bits)
  Signature Algorithm: SHA1 with RSA Encryption
  Issuer Name: 
    hostname=ASA1.NETWORKLESSONS.LOCAL
    cn=ASA1.NETWORKLESSONS.LOCAL
  Subject Name:
    hostname=ASA1.NETWORKLESSONS.LOCAL
    cn=ASA1.NETWORKLESSONS.LOCAL
  Validity Date: 
    start date: 14:03:52 UTC Dec 10 2014
    end   date: 14:03:52 UTC Dec 7 2024
  Associated Trustpoints: SELF_TRUSTPOINT

 The Issuer name (this is the CA) is the same as the Subject name because
 the ASA signed its own certificate. The certificate is ready but we 
still have to enable the trustpoint on the outside interface (where the 
SSL users terminate):

 ASA1(config)# ssl trust-point SELF_TRUSTPOINT outside

 ASA1(config)# crypto ca export SELF_TRUSTPOINT identity-certificate 

The PEM encoded identity certificate follows:
-----BEGIN CERTIFICATE-----
MIICEzCCAXygAwIBAgIENw2HVDANBgkqhkiG9w0BAQUFADBOMSIwIAYDVQQDExlB
U0ExLk5FVFdPUktMRVNTT05TLkxPQ0FMMSgwJgYJKoZIhvcNAQkCFhlBU0ExLk5F
VFdPUktMRVNTT05TLkxPQ0FMMB4XDTE0MTIxMDE0MDM1MloXDTI0MTIwNzE0MDM1
MlowTjEiMCAGA1UEAxMZQVNBMS5ORVRXT1JLTEVTU09OUy5MT0NBTDEoMCYGCSqG
SIb3DQEJAhYZQVNBMS5ORVRXT1JLTEVTU09OUy5MT0NBTDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEArJmiL8KQeh6G3fRQPcECcmEdgHftV2KoV7KX7mCVIEac
Lb71DFzhrDnLoZmPlQST+L+93fqt9wzB8yLyCiSw23/Z5WGgJNGfb1OAVi54SAF+
D4gWdzLFrvUPgOZDFCAHRbn0khf53zHKWi8F/mr277OI1CSiI1VxEkWPwg8CL38C
AwEAATANBgkqhkiG9w0BAQUFAAOBgQBSKiK9wkb5FEd/XnhOO3firGua5yqHF1JN
cDqav7FSJa5o4biBHjYjzy24uvDPPbdXVplIWSE/lHGb9kLrOCF2SN4fY+tCEzST
QqwAWrJnXDpolGViksdNwIjPuJSzoGeC9jLHFhWVM1sPBQeoHX9D9PSD0G0K8qs4
uzrlJWfMqg==
-----END CERTIFICATE----

 Copy and paste this in a text editor entirely, including the “—–BEGIN 
CERTIFICATE—–” and “—–END CERTIFICATE—–“. Save the file with a .pem 
extension. My file is called cert.pem.

Client Configuration

We are now ready to import the certificate on the user’s computer. I’ll be using Windows 7 for this. Click on the Start button, click on Run and enter “certmgr.msc”. This will open the certificate manager and you will see the following screen:

Here’s where you can manage all certificate on your Windows 7 computer. The certificate from the ASA should be imported in the Trusted Root Certification Authorities:

Use a right-mouse click on Trusted Root Certification Authorities, select All Tasks and then choose Import. You will see the following screen:

Click on Next and you will see this screen:

Select the cert.pem file and click Next. Here’s what you will see:

Make sure you have selected the Trusted Root Certification Authorities or the certificate will end up in the wrong folder. Click Next to continue and this is what you get:

After the import has completed, click Finish. You will receive a warning:

The security warning asks us if we really want to install the certificate…sure we do! Click Yes to continue and it will be done:

Click OK to finish this and you will see the certificate in the overview:

Great, the certificate has been imported. Now we need to make sure that we access the ASA using its FQDN (ASA1.NETWORKLESSONS.LOCAL) and not by its IP address. If you don’t have a DNS server then you can change your hosts file so that Windows 7 knows how to reach the FQDN. Click on Start, Run and then enter this:

 notepad c:windowssystem32driversetchosts

Don’t just hit ENTER but use CTRL+SHIFT+ENTER. This will run the command above with administrator rights. If you don’t, you will be unable to save the hosts file.
You can add a line like this:

10.10.10.1  ASA1.NETWORKLESSONS.LOCAL

Save the file and exit notepad. Whenever we try to reach ASA1.NETWORKLESSONS.LOCAL, Windows 7 knows that it is reachable on IP address 10.10.10.1. Open your web browser now and enter “HTTPS://ASA1.NETWORKLESSONS.LOCAL” as the URL. This is what you will see:

The web browser now trusts the certificate, it doesn’t show us any certificate errors anymore!
This method works but it might be cumbersome if you have many remote users to support. In another lesson we will take a look how we can request a certificate from a trusted CA so that you don’t have to import the certificate manually on all your user computers.