What We Will Configure
Our goal is to create an IPsec over UDP (NAT-T) Remote Access VPN Tunnel Mode with AES-256 encryption, SHA hash, D-H group 5, computer certificate-based IKE authentication, and user authentication using a RADIUS server. The Cisco VPN Client version 5.0 will be used as the client. So this is the highest possible security setting for an IPsec VPN. This is our primary goal.
At the same time, we will also provide information on what needs to be changed or set up twice in order to connect to the IPsec VPN from a device with Google Android OS and its native client, or the integrated client from Windows XP/Vista/7. This means creating an L2TP over IPsec over UDP (NAT-T) Remote Access VPN Transport Mode with 3DES encryption, SHA hash, D-H group 2, computer certificate-based IKE authentication, and user authentication using a RADIUS server. These clients do not support Perfect Forwarding Secrecy, Peer ID Validation, and IKE keepalives.
We will consider the network topology such that the Cisco ASA is connected directly to the internet and has a public IP address (so it is not behind a NAT). Clients can connect from both public and private (behind NAT) addresses. We'll discuss the topology in more detail later.
For user authentication, we will use a RADIUS server, but we won't discuss its configuration here. One option is to use the Microsoft Network Policy and Access Services (NPS), which is part of Windows Server 2008. On it, we'll set up the client (Cisco ASA) and create a Network Policy. We can place clients in an AD group and choose this group as a parameter for the NPS policy. As the Authentication Method, we will select only MS-CHAP-V2, and set Encryption to Strong Encryption 128 bit.
We will perform almost the entire configuration using the Java application Cisco Adaptive Security Device Manager (ASDM).
Note: It's important to note that the description is based on Cisco ASA version 8.4(1) and ASDM version 6.4(1). The configuration in older versions may be significantly different.
What the IPsec VPN Configuration on Cisco ASA Consists Of
For basic VPN setup, we can use the wizard menu Wizards - VPN Wizards - IPsec (IKEv1) Remote Access VPN Wizard. But we don't have to. The wizard won't set everything according to our preferences, so we'll need to adjust various items. And it also uses its own names for some items, I like to keep things tidy, so I rename them to my own preferences. Changing the name is usually just a matter of deleting and recreating the setting.
If we understand the theory of IPsec VPN and choose the protocols and algorithms we want to use, it's not too difficult to set everything up. However, it's important to understand how Cisco refers to the different areas and how they are dependent on each other. The main points for an IPsec VPN are as follows (of course, we also need to solve other auxiliary settings, such as DHCP Pool, local or AAA server users, etc.):
- IKE Parameters - global parameters for IKE, we enable NAT-T
- IKE Policies - in the policy, we set the parameters that are offered during the negotiation of IKE phase 1 for security (IKE SA), we can have multiple and they are prioritized based on priority, combinations like {pre-share, 3desc, sha, D-H group 5} and {rsa-sig, aes-256, D-H group 5, sha}, so what security will be used for the initial IKE part - SA negotiation
- IPsec Proposals (previously Transform Sets) - a group of operations performed on the data stream to ensure authentication, encryption, and compression, for example, the ESP protocol in Tunnel Mode with AES encryption and HMAC-SHA-1 authentication (ESP-AES-SHA), so what security will be used for IPsec ESP - the VPN itself
- Crypto Maps - selects the traffic to be secured and defines the policy for securing it, if we have only one, it's simple, the values are used for the negotiation of IKE phase 2 (IPsec SA), we assign the prepared IPsec Proposals
- Group Policies - determines the properties of network access after connecting to the VPN, we choose the VPN type (IPsec, L2TP/IPsec, SSL, etc.), policies for the client (use of FW, filters, access restrictions to VLAN, time, DNS server), split tunneling, so we restrict and control the client's access
- IPsec(IKEv1) Connection Profiles (previously Tunnel Group and even earlier VPN group) - defines the key values for creating the session, such as authentication, IP address assignment, we set the Group Policy to be used

The Process of Establishing an IPsec VPN
- IKE phase 1 is negotiated according to the IKE Policies settings
- Within phase one, authentication is performed either using a computer certificate (rsa-sig) or a Pre-Shared Key (pre-share)
- From the data in the certificate (according to the settings on the ASA) or the username and PSK pair, the Connection Profile name to be used is determined
- If XAUTH is enabled, then user authentication is performed (local user or on RADIUS)
- User attributes - Group Policy (and others) are assigned
- According to the Crypto Map, the IPsec tunnel (ESP) is established
Profile Assignment
The name of the Connection Profile (tunnel group) is very important, because this name is used to assign the profile (policy) and thus most of the connection parameters are set for the user.
If we have IKE Peer Authentication set to Pre-shared Key (PSK), then in the Cisco VPN Client we choose Group Authentication, the name is the Connection Profile name and the password is the PSK.
If we set Identity Certificate, we choose Certificate Authentication and select the appropriate certificate. The Connection Profile name is searched for based on the set method, for example, based on the certificate OU.

Policy Assignment and Application
User attributes, more accurately called user authorization attributes (attribute-value pair), can be configured in several places. The main one is the Group Policy, but we can assign it to a user in several ways. Using the Connection Profile or setting it on the user (locally or from a RADIUS or LDAP server). The default Group Policy, from which the other policies inherit, also plays a big role. It usually depends on how large a group we want to set it for. Then, of course, it depends on the order in which they are applied. The values from the individual locations are combined, and if there is a conflict, they are overwritten in the order of application.
There is also a configuration area that we haven't discussed yet and won't be using in this article. Dynamic Access Policy (DAP) sets access parameters in a dynamic environment, we can control access at the individual session level - criteria are compared during session creation.
Order of Evaluation (Policy Enforcement):
- default Group Policy (DfltGrpPolicy) - global settings for everyone
- Group Policy assigned from the Connection Profile - most common use, based on the connection profile
- Group Policy assigned to the user - for example, on the RADIUS server
- user attributes from the AAA server - after user authentication, values can be accepted from the RADIUS or LDAP server
- Dynamic Access Policy - has the highest priority, what is set here, wins
If we want to assign a Group Policy to a user based on an attribute from the RADIUS server, we must set the RADIUS Standard Attribute 25 (Class) and put in it `OU=group policy name` and pass this value during user login (we'll describe this option in more detail next time). Caution: if we pass a non-existent policy name, the settings will not be applied! If we use an LDAP server, we can map any attribute to the Group Policy setting. For local users on the Cisco ASA, we can directly set the assigned Group Policy.
Practical Steps for Configuring an IPsec VPN
We performed the initial connection and startup of the ASA last time, now we will continue with further configuration. We will set up the network configuration, access, VPN users using the AAA server (RADIUS), and clients will receive IP addresses from the DHCP on the ASA. And then the actual VPN configuration according to the parameters mentioned in the introduction.
At the beginning, it is good (I would say directly necessary) to draw a diagram of the connection (topology), it doesn't have to be complex, but it is important to discuss the used addresses, subnets, and routing. I leave aside the global question of connection, such as placing the ASA behind another firewall, etc.

1. Configuring the ASA Device
Configuration > Device Setup > Device Name/Password
Hostname, domain, password for privileged mode.
Configuration > Device Setup > Interfaces
Security level - 0 (lowest) to 100 (internal network), divides networks, communication from lower to higher is usually not allowed, but the other way around is. We assign names to the interfaces that will be used further.
Ethernet0/0, name outside, security level 0, IP 86.55.13.15/24 Ethernet0/1, name inside, security level 100, IP 10.240.0.1/24 Management0/0, name management, IP 192.168.1.1/24
We can consider enabling the two items at the bottom of the page:
Enable traffic between two or more interfaces which are configured with same security levels Enable traffic between two or more hosts connected to the same interface
Configuration > Device Management > DHCP > DHCP Server
By default, DHCP is enabled on the management interface, if we don't need it, we can disable it.
Configuration > Device Management > Users/AAA > AAA Server Groups
Configuration of the AAA group, in which we include one or more RADIUS servers.
Configuration > Device Setup > System Time > NTP and Clock
Setting the NTP server and time zone.
Configuration > Device Setup > Routing > Static Routes
We'll add a default GW for clients (how VPN clients connect from the internet so they can get a response).
outside, any, 86.55.13.254, 1
We'll add a default GW for clients inside the VPN (when they have an IP from this range, to access the internal network).
inside, any, 10.240.0.254, 255, Tunneled
We may also need to add a route for access to the RADIUS servers (and others like Syslog, NTP).
Configuration > Firewall > Access Rules
For information only, we don't need to change anything here. At the bottom of the page, we'll choose IPv4 Only. In the Global section, there are rules that apply everywhere, by default there is a final deny any any. On the inside interface, we have an implicit rule allowing communication to networks with a lower security level (security level).
Configuration > Firewall > NAT Rules
There may be some unnecessary items, but this configuration is functional.
- from VPN_subnet address to VPN_subnet, both ways, static NAT - don't NAT between clients in the VPN
- from VPN_subnet address to local_subnet, both ways, static NAT - don't NAT between VPN and local clients
- from VPN_subnet address to outside interface, dynamic PAT (Hide), translate source outside - NAT the rest
Network Objects - when setting up NAT, we'll create objects:
- local_subnet - 10.0.0.0/8
- VPN_subnet - 10.240.0.0/24
Note: At the top of the menu, we can use the Diagram button, which roughly outlines the schema of a particular rule, or the Packet Trace, which simulates communication.
Configuration > Device Management > Certificate Management > CA Certificates
We'll install the Certificate Authority (CA) certificate from which the ASA and clients have a certificate (.cer).
Configuration > Device Management > Certificate Management > Identity Certificates
We'll install the certificate for the ASA (with a private key, will be used to establish IKE phase 1, .pfx)
Configuration > Remote Access VPN > Network (Client) Access > Address Assignment > Address Pools
We'll prepare the address range for the DHCP VPN_Pool - 10.240.0.100 to 10.240.0.200.
2. Configuring the IPsec VPN
Configuration > Remote Access VPN > Introduction
Here we'll start with the configuration of the VPN itself. We can either use the wizard, which will pre-prepare some values for us, or we'll set it up manually.
Wizards - VPN Wizards - IPsec (IKEv1) Remote Access VPN Wizard
- VPN Tunnel Interface = outside
- Cisco VPN client
- Authentication Method = certificate
- Tunnel Group Name = Firma_policy
- Authenticate using an AAA
- Pool Name = VPN_Pool
- Encryption = AES-256, Authentication = SHA, Diffie-Hellman Group: 5
Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > IKE Parameters
We'll check the enabled Enable IPsec over NAT-T
Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > IKE Policies
IKEv1 Policies, we need a policy with priority 1 and authentication values rsa-sig (i.e., certificate, pre-share would be PSK), encryption: aes-256, hash: SHA, D-H Group: 5.
For MS/Android, we must add a second IKEv1 policy option with encryption: 3DES, hash: SHA, authentication: rsa-sig, D-H Group: 2.
If we have multiple policies, the highest priority is 1, if the peers don't agree on this one, they'll try the next one.
Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > IPsec Proposals (Transform Sets)
For Cisco, the most secure option is sufficient for us, the Transform Set in Tunnel mode with ESP Encryption AES-256 and ESP Authentication SHA.
For MS/Android, we can only use weaker security, the Transform Set in Transport mode with ESP Encryption 3DES and ESP Authentication SHA.
We can set up both options again.
Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > Crypto Maps
We have the default dynamic Crypto Map with priority 65535, in the IKE v1 IPsec Proposal we should have the groups (one or two) that we created in the previous step. If we will only use the Cisco VPN client, we can have Enable Perfect Forwarding Secrecy (PFS) checked on this page. On the Tunnel Policy (Crypto Map) - Advanced tab, we'll check Enable NAT-T.
Configuration > Remote Access VPN > Network (Client) Access > Group Policies
We can use one or more Group Policies, if we want to provide different parameters to some clients, or just edit the default DfltGrpPolicy policy. Let's say I have the Firma_policy policy. We'll leave most of the values Inherited, but in the General tab, we'll expand More Options and in the tunneling protocols check IPsec IKEv1, and if this policy is also to work for MS/Android, we must also check L2TP/IPsec. In Servers, we'll enter the addresses of the DNS servers, or WINS servers if needed.
The values that are Inherited are taken from the default DfltGrpPolicy policy. In each policy, we can optionally set a number of parameters that are otherwise set in another location, but this way they will only apply to the selected group of users. An example is the Advanced > IPsec Client option to enable/disable Perfect Forwarding Secrecy (PFS). We can also go through the default settings of the DfltGrpPolicy policy to get an overview of what is set and possibly adjust it.
Configuration > Remote Access VPN > Network (Client) Access > IPsec(IKEv1) Connection Profiles
This part was previously called Tunnel Groups (and the command is still the same). In the top part of the page, we select the interface on which we will allow IPsec access, we must enable Access Interfaces - outside. Based on the Group Policy, we create one or more profiles, for example Firma. There is also a default profile DefaultRAGroup that we can use in certain situations. The values we set:
- IKE Peer Authentication - Identity Certificate - we select the ASA certificate
- User Authetication - Server Group - our AAA group
- Client Address Assigment - Client Address Pools - VPN_Pool
- Group Policy - Firma_policy
- enable Enable IPsec protocol
- Advanced > IPsec - IKE Peer ID Validation - Required
- Advanced > IPsec - IKE keepalive - Monitor keepalives - confidence 300s, retry 2s
- Advanced > IPsec > IKE Authentication Mode - XAUTH
- Advanced > PPP - select only MS-CHAP-V2
For MS/Android, we must change some values:
- also enable Enable IPsec protocol and Enable L2TP over IPsec protocol
- Advanced > IPsec - IKE Peer ID Validation - Do not check
- Advanced > IPsec - IKE keepalives - Disable keepalives
Note: IKE keepalives don't need to be disabled, they serve to send and monitor messages, if the messages don't come, the ASA removes the connection. If the client doesn't support this feature, only an informational log is recorded and nothing happens.
Via CLI - Setting a parameter for the Connection Profile
We need to enable password changing via VPN on the profile, only then will MS-CHAP-V2 be enabled, until then PAP is used and the login would not work (if we have only MS-CHAP-V2 enabled on the RADIUS server). This is quite an interesting trick discovered by my colleague. Otherwise, most online guides say that PAP must be used on the RADIUS server, which is not a secure option at all.
ASA(config)#tunnel-group Firma general-attributes ASA(config-tunnel-general)#password-management
Configuration > Remote Access VPN > Network (Client) Access > Advanced > IPsec > Certificate to Connection Profile Maps > Policy
When using certificates in the first phase of IKE, we set here how the assigned Connection Profile is determined. By default, the preset DefaultRAGroup profile is used. For simplification, we can set Default to Connection Profile to Firma. But if we have multiple profiles or want more security, we'll choose a different setting and determine the profile name based on some value.
Monitoring VPN
Basic information about monitoring and troubleshooting VPN on the ASA. The first setup is done on the Home page at the bottom, where we enable logging.
Monitoring > Logging > Log Buffer
Here we can view the latest logs stored in memory.
Monitoring > VPN > VPN Statistics > Sessions
Active VPN connections.
Configuration > Device Management > Logging
Logging configuration.
Configuration > Device Management > Logging > Syslog Servers
Setting the Syslog server over which interface it is connected. The default syslog port is UDP 514.
Configuration > Device Management > Logging > Logging Filters
We set the levels and types of messages we want to send to a particular device. For example, for ASDM All event severity Notification and for Syslog Servers we define a list of selected events we want to send Use event list.
Configuration > Device Management > Logging > Event Lists
List of events to be sent. VPN All Event Class Errors + Message ID Filters 113019, 713120, 713123, 713228 (events about user login and logout from VPN).
Ahojte,
k čemu se prosím vyplatí VPN site to site? nebude potřeba použít VPN klienta..nic víc?díky
respond to [1]ZAJDAN: Site to Site vs. Client Access VPN mají úplně jiný význam. Site to Site je propojení dvou sítí dohromady přes internet, takže tak připojíme třeba pobočku a všechna komunikace všech uživatelů funguje. Kdežto Remote Access pouze připojí jednoho klienta do cílové sítě.