VPN 2 - Introduction to Cisco ASA and VPN Options

The models start from the small 5505 and 5510 (which may be sufficient for a number of companies in the Czech Republic) through more powerful models 5520, 5540, 5550 to the powerful 5580 and 5585. Cisco ASA combines several types of devices (which were previously sold separately). Its features include Firewall, Intrusion Prevention System (IPS), VPN Concentrator, antivirus (content security), network services (routing). Some features are licensed separately (must be purchased). Cluster configuration and thus high availability are supported for most models.

The Java application Cisco Adaptive Security Device Manager (ASDM) is used for configuration, which can be downloaded directly from the ASA via the web interface (or run directly). Or the standard via the command line interface - CLI (Command Line Interface). ASDM offers a nice graphical interface where we can configure most of the features. Although I'm a proponent of using CLI (IOS) on switches, for ASA (so far) I prefer ASDM.

In the VPN area, ASA offers IPsec site-to-site or remote access VPN, where a significant number of clients are included in the base price. Furthermore, the more modern SSL VPN and IPsec IKEv2 VPN, for both of which special licenses and the AnyConnect client are required. Clientless SSL VPN (otherwise known as Web VPN) and mobile VPN (support for mobile clients) also require a license. In SSL VPN, there is the Cisco Secure Desktop technology, which tests the client station, creates a virtual environment (encrypted desktop) in which work is performed when connecting to the VPN, and upon disconnection, all temporary data is overwritten (thoroughly deleted). It also supports various client checks (AV, FW, updates) before connecting to the VPN and policies (ACL, access restrictions) after connecting.

In conclusion, Cisco primarily focuses on the AnyConnect client, which offers great functionality, but is licensed separately and its use is expensive.

ASA and ASDM Versions

The operating system on Cisco ASA is not referred to as IOS, but simply as ASA software. It's not entirely the same as IOS, but it's quite similar.

Recently, ASA version 8.2 was widespread, with the introduction of version 8.3 there were a number of extensive changes, and version 8.4 (currently the latest) added a few more. For example, a novelty is the support for IPsec VPN via the AnyConnect 3.0 client, but there's a catch that IKEv2 must be used and the SSL license (AnyConnect license) is consumed, not the IPsec license (of which we have many). In the new versions, the placement of items in ASDM has also changed a lot, for ASA version 8.4 the ASDM version 6.4 has quite poor help (links don't work, menu locations, etc.). For a certain version of ASA, we always need the corresponding version of ASDM.

Changing the ASA and ASDM Version

Just like with a switch, we can have several IOS versions stored and start a specific version, so with ASA we can have several ASA and ASDM versions. The choice of the default ASA image is done as follows (in this case, disk0: is equivalent to flash:).

ASA(config)#boot system disk0:/asa841-k8.bin

The choice of the default ASDM is similar.

ASA(config)#asdm image disk0:/asdm-641.bin

First Access to the ASA

• in the factory settings, the ASA has the IP address 192.168.1.1, we connect to it over the network via the MGMT interface, on which DHCP is running
• the default address is https://192.168.1.1/admin/public/index.html
• the default username and password are empty
• then we install ASDM and connect to it
• initial configuration using ASDM - menu Wizards - Startup wizard

Displaying Commands Before Sending

ASDM has a nice feature that when we save changes made in the graphical environment, it can show us the commands it will execute. This is an ASDM setting and is located in the menu Tools > Preferences, where the following item is located:

Preview commands before sending them to the device

Enabling SSH

As an initial configuration step, it's a good idea to set up the options for how to connect to the ASA. By default, SSH is not enabled. The configuration of the access is located at:

Configuration > Device management > Management Access > ASDM/HTPS/SSH/Telnet

The default SSH username is asa and the password is cisco. The default enable password is empty. Setting up users for authentication:

Configuration > Device Management > Users/AAA > AAA Access > Authentication

Users

For security, we need to set a password for the privileged mode (enable password):

Configuration > Device Setup > Device Name/Password

And an administrative account for logging in to the ASA (of course, we can set up authentication via RADIUS, but for communication issues, it's good to have one local account):

Configuration > Device Management > Users/AAA > User Accounts

Routing on ASA and VPN

Let's take a look at a few more advanced features that we'll use next time when we create an IPsec VPN.

When routing a packet on a Cisco ASA with a connected VPN client, the following steps are followed:

• first, a learned route (directly connected interface) or a static route is searched for
• if not found, then
  • if the traffic is encrypted (i.e., VPN), it is sent to the Default Tunnel Gateway (DTGW)
  • in the opposite case, it is sent to the Default Gateway (DGW)

Static routes are configured in

Configuration > Device Setup > Routing > Static Routes

Management interface

The special management interface is not routed with other interfaces, but the routing table is calculated with it. When a request comes in that should go through the management interface, it is dropped.

Commands

Displaying the routing table is a bit different than on a switch.

ASA#show route

For testing, we can use extensions of the basic commands, such as ping with the specification of the interface.

ASA#ping management 10.0.0.10

Or display the route for a specific address and interface.

OKVPN#show route inside 10.0.0.10
Gateway of last resort is 86.55.13.254 to network 0.0.0.0
S    10.0.0.0 255.255.255.0 [1/0] via 192.168.10.254, inside
C    192.168.10.0 255.255.255.0 is directly connected, inside
S    0.0.0.0 0.0.0.0 [255/0] via 192.168.10.254, inside tunneled

VPN Authentication Using Certificates and RADIUS Server

In the next part, we will focus on configuring the IPsec Remote Access VPN, where the computer will be authenticated using a certificate and the user through RADIUS using an AD account. Here we'll look at the related issues.

Client Computer Certificate

In the first phase of IKE, communication security will be achieved by encryption using the server and client certificates. At the same time, this means that the client will be authenticated by this certificate (if the defined conditions are not met, the communication is rejected). We will use the MS CA, which is part of the Windows Server, to issue the certificate.

In the Microsoft Certification Authority (CA), a certificate for IPsec is created with the purpose (Intended Purposes), or otherwise usage (Enhanced Key Usage), IP Security IKE Intermediate (OID 1.3.6.1.5.5.8.2.2). But Cisco requires the IP Security Tunnel Endpoint purpose (OID 1.3.6.1.5.5.7.3.6). If the certificate purpose is incorrect, an error is logged on the ASA when using the certificate:

ERROR: Certificate validation failed. Peer certificate key usage is invalid, serial number:

On the ASA, we can disable this check, but it's better to issue the certificate with the required purpose (which is not a problem on MS CA, we set Type of Certificate Needed: Other and fill in OID: 1.3.6.1.5.5.7.3.6).

ASA(config)#crypto ca trustpoint MOJE_CA
ASA(config-ca-trustpoint)#ignore-ipsec-keyusage

User Authentication via MS RADIUS - NPS

In the next step of IKE, the XAUTH extension is used, which allows us to authenticate the user against the RADIUS server and thus against Active Directory. The possible configuration is as follows. We will use the Network Policy and Access Services (NPS) from Windows Server 2008 as the RADIUS server. The ASA is the client, and we configure a shared secret for the connection. On NPS, we create a Network Policy where we set Grant access and Ignore user account dial-in properties. The conditions are: based on the client ASA and Windows Group G VPN (so we can control which clients can connect to the VPN). We enable authentication using MS-CHAP-v2. Encryption only Strongest encryption.