TAZ Forum Community

Configuring Virtual Private Networks with the Cisco PIX Security Appliance

Historically the only feasibly secure method to connect two remote sites together was via a costly leased line or ISDN line. Although leased lines are still perfectly acceptable in some situations, the variety of VPN solutions available on the market today make a VPN topology and more flexible and economical solution to adopt.

A Virtual Private Network or VPN is a service that provides a means for secure and reliable connectivity over a public infrastructure, such as the Internet.

VPN’s can be divided into three common types depending on what components are accessing the VPN.

Access VPN:
An Access VPN is a secure means for remote workers to access the corporate network from home or any other remote location. Typically an access VPN comprises of software installed on the clients computer that ‘dials in’ to a VPN end point such as a PIX, authenticates the user and allows them to access parts of the network that have been defined in the VPN configuration. This type of VPN is commonly called a Remote Access VPN.

Extranet VPN:
An Extranet VPN is in essence an Intranet VPN in so much as no software is required to be installed on any remote hosts and the configuration is all done between the two end points. Typically an Extranet VPN is used for connectivity to customer networks and the network access is granted at both ends of the tunnel; usually restricted to certain hosts only.

Intranet VPN:
An Intranet VPN is used between two sites that belong to the same company and is commonly referred to as a site-to-site VPN. Usually it provides full and unrestricted access to the enterprise LAN and acts as seamless extension to the LAN – the end uses may very well never know the VPN exists.

This paper will cover Extranet and Intranet VPN’s. Access VPN’s will be covered in a later paper due to the size of the subject.

Extranet and Intranet VPN’s are configured almost identically, with the only difference being is that an extranet VPN may restrict what hosts can be reached via the VPN. The actual secure channel is setup and configured the same way and uses IKE and IPSec.


Internet Protocol Security (IPSec)
IPSec is not in itself a protocol, it is more a combination of other protocols and algorithms bundled together to provide data security at the network layer to address the inherent weaknesses in Internet Protocol.

IPSec uses Internet Key Exchange (IKE) to create a secure channel between two end points, known as a Security Association, before establishing the IPSec part of the VPN tunnel.

The method of establishing the VPN is broke into two phases; IKE Phase one and IKE phase two.


Internet Key Exchange (IKE)
IKE is the abbreviated abbreviation (eh?) for Internet Security Association and Key Management Protocol with Oakley distribution commonly known as ISAKMP (pronounced ice-a-camp). ISAKMP and the Oakley and Skeme key exchange are two different protocols, but are collectively known as IKE.

ISAKMP is defined in RFC 2408 and dictates the format used for the management of IPSec connections, however it does not include any [cryptographic] key management functions , in-other-words it doesn’t say how the keys should be shared with the two peers or how often they should be changed. To address these two limitations we use IKE in conjunction with ISAKMP. For the sake of VPN management the terms IKE and ISAKMP generally refer to the same thing and either can be used, for the rest of this paper I will use the term IKE.

IKE operates over User Datagram Protocol (UDP) on port 500 and is used to negotiate a mutual key exchange to create a secure path between two peers (end points). This secure connection is established in two phases, the first phase is used to establish the IKE Security Association (SA) and the second phase establishes the IPSec SA.

IKE provides the following functions:

Provides antireplay protection for IPSec communications
Provides a means to define an SA’s life-span
Supports Certification Authorities (CA’s)
Automatically negotiates the parameters for SA’s which reduces the manual configuration involved in setting it all up
Permits the encryption key to be changed dynamically with out the need to tear down the IPSec session.
Provides a very flexible approach to setting up IPSec connections

It may seem a bit confusing at first but think of it like this:

Before you set up an IPSec connection with a remote node, we need to know that the remote node we are talking to is in fact the node we want to set up the VPN tunnel with. After we have verified the identity of the remote node we also need to share the cryptographic keys between the two nodes in a secure manner – this is the job of IKE phase one. After this has been established we need to set up the IPSec part of the connection and the two nodes will use the secure IKE channel setup in phase one to establish the IPSec tunnel.


IKE Phase One
As mentioned IKE comes into play in phase one by setting up an SA between the two IKE peers. If IKE does not first establish an SA in phase one, then the IPSec SA in phase two will never take place.

**A Security Association (SA) is in plain terms a set of rules two end points agree to use and accept for the duration of that particular SA, such as encryption algorithms and hashing algorithms etc. **

During the IKE SA establishment he following must be mutually negotiated between the two end points:

1. Encryption Algorithm
2. Hash Algorithm
3. Authentication Method
4. Diffe-hellmen group

Once the two end points agree on what they are going to use for all of the above, a bidirectional SA is established which then allows the IPSec SA to take place.

Phase one can be established in one of two modes; Aggressive mode or Main Mode.

Main Mode
Main mode negotiation consist of six message exchanges that mirror each other between the two peers and is used if you are using certificates to authentic remote peers. The message exchange is as follows:

1 – Initiator; negotiates an exchange policy
2 – Responder; negotiates the exchange policy
3 – Initiator; exchanges Diffe-Hellmen public keys and a random value between 8 – 256 bits, called a nonce.
4 - Responder; exchanges Diffe-Hellmen public keys and a random value between 8 – 256 bits, called a nonce
5 – Initiator; authenticates the Diffe-Hellmen key exchange
6 – Responder; authenticates the Diffe-Hellmen key exchange

Initiator Responder
IKE Header with SA payload -------- > -------- > --------- > --------->
<--------- < -------- < -------- < --------- < ----------- IKE Header with SA payload

IKE Header Key Exchange Nonce (initiator) -------- > -------- > -------- >
<-------- < -------- < -------- IKE Header Key Exchange Nonce (Responder)

IKE Header (payload is now encrypted)
Identification Hash Payload (initiator) -------- > -------- > ------ >
<-------- < -------- < -------- < -------- < -------- IKE Header (payload is now encrypted)
Identification Hash Payload (initiator)

Aggressive Mode
Aggressive mode only has three exchanges and is used if you are using Pre-Shared Keys (PSK’s) for authentication. The first two exchanges negotiate the policy to use, exchanges public keys and authenticates the responder. The third message authenticates the initiating peer and is sent in encrypted text after the negotiation has finished.

**Diffe-Hellmen (DH) is a public cryptography protocol that two IPSec peers use to come up with a shared secret over an unsecured means such as the Internet, without actually having to send the key to each other. The mathematics behind it are ingenious; each peer will create a public and private key using a DH group, these peers then send their public keys to each other, next the peers run the public key they have just received and their own private key (which has never been shared with the other peer) through the DH algorithm and come up with a fixed length value that will be identical on both hosts... this is the shared key they will use to encrypt the subsequent key exchange for the SA to be established.**

During this phase one exchange, rather than negotiate each parameter individually, i.e. negotiate 3DES for the encryption standard and then negotiate SHA-1 for the Hash standard etc, the algorithms are grouped in to sets, called transform sets or IKE transform sets to be exact. These transform sets will delineate what standards can be used for encryption, authentication, key length and the mode to be used. Once a common transform set has been mutually agreed upon during the first message exchange the main Mode/Aggressive Modes exchange can continue. If a common transform set can not be found the tunnel is closed down and the IKE SA will not occur.

For any peer to participate in an IPSec session it is essential for them to first authenticate each other via either main mode or aggressive mode as otherwise IKE phase two can not start. Hence the need for IKE Phase One.

Which brings us on to the IPSec part of the setup process:

IKE Phase Two
Having successfully authenticated each peer and establishing a secure channel for further communications, IKE Phase One evolves in to Phase Two.

As mentioned phase two can only occur after the IKE SA negotiation has completed. Phase Two’s main purpose is to negotiate mutual policies for non ISAKMP SA’s such as the IPSec SA and to derive the keying material to be used.

Phase Two only has the one mode, called Quick Mode.

Once the secure tunnel has been setup by Phase One, Phase Two negotiates the IPSec parameters to be used such as the various algorithms, Shared Secret keying material etc. It is also used to re-negotiate the a new SA once the predetermined life-span of the current IPSec SA has expired.

IPSec has two main protocols, ESP and AH.

**I will cover the encryption and hashing standards first – if they seem confusing at first it will all become apparent later on when the VPN gets configured**

Encapsulating Security Payload – ESP
ESP is an extensive protocol that provides antireplay services, data authentication and data encryption and is primarily responsible for securelygetting the data from the source to the destination in such a way that the destination host will know if the data has been tampered with hence ensuring that your session can not be effectively hijacked.
ESP is versatile enough to be able to encrypt either just the payload of the packet or the entire data packet and can also authenticate the sender of the data either in conjunction with Authentication Header or on its own.

IPv4 Packet Encrypted with ESP:
_________________________________________________________________________
|IP HEADER | ESP HEADER | TCP INFO | DATA | ESP TRAILER | ESP AUTHENTICATION |
``````````````````` --------- ENCRYPTED BY ESP ---------- ``````````````````````````
the ESP Header and all up to and including the ESP Trailer is Authenticated by ESP

Authentication Header
Authentication Header pretty much does as it names suggests, it authenticates the information that is in the IP Header, or in other words it ensures that the data did originate from where it says it does in the header by means or origin authentication. By doing this is provides antireplay services and prevents your session being hijacked. It may seem similar to ESP but the one glaring difference is that AH does not provide any data encryption, its only purpose is to authenticate the sender.

One major downfall with AH is that it is not compatible with Network Address Translation (NAT). Due to the address translation occurring before the IPSec SA being established, by altering the sending IP address you would cause the AH hash that confirms the sending source to fail.

IPv4 Packet with AH
__________________________________________________________
| IP HEADER | AUTHENTICATION HEADER (AH) | TCP | DATA |
``````````````````````````````````````````````````````````
As you can see no encryption takes place, unlike ESP which encrypts the payload of the packet.

**ESP and NAT is supported by the PIX by way of a fix-up protocol that inspects ESP on a more granular level**

ESP and AH can be configured to use different algorithms to encrypt and hash the data.

**An Encryption Algorithm is used to encrypt the data where as a Hash Algorithm is used to provide data integrity**

The PIX will support the following encryption algorithms:

Data Encryption Standard (DES):
DES is a 56 bit symmetric encryption algorithm. Although it is somewhat outdated now it is included with the PIX for legacy reasons and should not be used if there is another option available. Due to US technology export restrictions it is more commonly used outside the USA.

Triple Data Encryption Standard (3DES):
3DES as it name suggests it three time as strong as DES by way of a 168 bit symmetric cipher which is obtained by encrypting the data three consecutive times using DES. More specifically the data is first encrypted using a 56 bit DES key, then decrypted using another 56 bit DES key and then re-encrypted using yet another 56 bit DES key.

Advanced Encryption Standard (AES)
AES is a symmetric block cipher that encrypts and decrypts the data using cryptographic keys of 128, 192 or 256 bit lengths. The resulting encrypted data is then placed into 128 bit blocks which are combined into cipher block chains.

**Symmetric encryption uses only a single secret key by itself to encrypt and decrypt the data. Asymmetric encryption uses a key pair -- both a public and a private one -- for encryption and is commonly used for Certificates. The sending host uses the receiver's public key to encrypt the data and the receiver uses their private key to decrypt it.**

Message Hashing
A hash algorithm simply talks the message, puts is through an algorithm and creates a fixed length Message Digest (MD) from it. This message digest is then put into another algorithm called a digital signature algorithm which in turn generates a signature (or hash) for the message from the message digest, rather than from the actual message, which reduces the processing time of the message. Should the data be altered even slightly it will massively throw out the message digest (which remember is derived from the original data) and as a knock on affect the signature (or hash) will be invalid.

For the hash to be created at the sending station and then understood at the receiving station both stations must be using the same algorithms.

The PIX will support the following hash algorithms:

Secure Hash Algorithm 1 (SHA -1)
SHA -1 produces 160 bit output and is considered more secure than MD5 for this reason

Message Digest 5 (MD5)
MD5 output is 128 bit. It is considered faster that SHA -1 but less secure.



IPSec Session
Once Phase One and Phase two are established, traffic deemed interesting for the IPSec session will flow through the tunnel in encrypted form. The tunnel is not an ‘always on’ means and will time out after either a predefined time limit is reached or a predefined amount of data has been sent through it.

One of the main weak points with any encrypted service is the amount of data sent in the encrypted form that had been encrypted using the same keysets. The more data that can be collected the easier it may be for the encryption algorithm to become compromised ( you only have to look at WEP for a perfect example of this). For this reason the SA’s established will time out either after a predefined amount of time or a predefined amount of data has been sent through the IPSEC tunnel. When the SA times out IKE performs a whole new Phase Two negotiations and if needs be a new Phase One negotiation. This is done before the current SA times out to prevent any interruption in the data flow.

Just as a quick summary for those who may not have followed it so far:

IKE Phase One provides a low level set of security services via policies/standards that are first negotiated and then mutually agreed upon once common ground has been found. Once this secure channel has been established IPSec can use this secure channel to set up the IPSec Security Association (SA) in Phase Two.

**As mentioned earlier without Phase One there would be no way to verify that the end point in use when you set up the IPSec SA is actually the correct end point and that in fact you are not setting up your IPSec tunnel with an attacker of some kind**

IKE Phase Two is where IKE negotiates the IPSec SA’s parameters via the secure link setup in Phase One and sets up the IPSec ‘tunnel’ between the two peers. This established IPSec SA is what then protects all the resulting traffic that flows between the tunnel end points. IPSec uses IPSec transform sets in the same way IKE uses IKE transform sets. Again just like IKE, if no common transform set can be agreed upon the connection is torn down and the IPSec VPN fails.

Most Cisco products support three methods of IPSec peer authentication:

RSA Signatures (Certificates) - This is considered the preferred method of authentication as it uses digital certificates that are authenticated by an RAS Signature.
Pre-shared Keys – As the name suggests these are manually configured case sensitive keys that must exactly match on both peers.
RSA Encrypted Nonce’s - Cisco appliances can use RSA (Rivest Shamir Adleman) encryption to encrypt a random number (a nonce) that is generated by the peer along with other pre configured values. The PIX does not support this type of authentication at this moment in time.


Certificates and Certification Authorities (CA)
Certificate authorities manage certificate requests, issue the requested certificates once approved and publish Certificate Revocation Lists (CRL’s, pronounced “Crills”). IKE understands X.509v3 certificates that require public keys.

A digital certificate has a public key, which is available publically strangely enough, and is used for the automatic authentication of servers and/or users. The connecting node needs to trust the root CA that issued the certificate for it to accept it. By default the connecting node also needs access to the CRL to check if the certificate has been revoked by the root CA. Some third party CA’s are already trusted for web browsers etc but the PIX will only trust the following third party CA’s:

VeriSign
Microsoft Corporation
Baltimore Technologies
Entrust Corporation

Certificates replace the need for pre-shared keys as they already have a public and private keys as part of the frame work of the certificate.
For certificates to work on the PIX there are four steps to take:
Generate an RSA Key pair

Obtain the CA’s certificate which will have the public key
Using the generated key and the public key obtained by the CA the firewall will then request a signed certificate from the CA
The CA then verifies the request and offers the signed certificate to be published (depending on how the CA is configured this sometimes requires an administrator to manually approve the request)

Pre-Shared Keys
Pre-Shared Keys (PSK) are usually used if you only have a few firewalls to configure and you control all of the firewalls in the VPN configuration, as when you change a PSK on one firewall obviously you will need to change it on the other. PSK’s offer the quickest and easiest way to configure a VPN. A PSK can be up to 128 bytes long and uses alphanumeric characters ( A-Z and 0-9)

Configuring the PIX for VPN Usage
When configuring site-to-site VPN’s sometimes you can be dealing with an administrator from another organisation, or you could be lucky enough to be the administrator of both the VPN peers. Either way it is always a good idea to write down the exact configuration that will be entered on both firewalls, such as the transform set, pre-shared key (if using one), peers IP address etc. Most VPN configurations run into problems because the configurations do not mirror each other.
If you are dealing with an administrator from another company I have always found it better in the long run to email each other with the configuration you are going to use but then to phone each other up and configure the firewalls at the same time, this way you will ensure you are entering the same information on the firewalls and can exchange a PSK verbally which is obviously more secure than doing it by email.
The whole process could be broken down into 8 steps (you could also use these steps to troubleshoot problems)

1.Can you ping the remote peer IP address – If you cant establish non-VPN connectivity to the remote peer then you are never going to establish a VPN connection. (if you are dealing with a remote administrator ensure his firewall will respond to ICMP requests)
2.Design the topology/layout of the VON and ensure it meets all company security requirements
3.Allow IPSec traffic into your network with an ACL
4.Configure an ACL to determine with traffic to protect (encrypt)
5.Decide on a mutual configuration policy for IKE phase 1
6.Decide on a mutual configuration policy for IKE phase 2
7.Verify the configuration once finished
8.Check the status of the connection

There are many ways to configure a VPN and many different commands can be used depending on your configuration but ultimately they all fall somewhere within the above steps. As mentioned you can use the above steps to troubleshoot any VPN problems:

Can you ping the peer
Have you permitted IPSec traffic into the PIX
Is your ACL protecting the right traffic
Do the IKE phase one parameters match
Do the IKE phase two parameters match
What state is the VPN connection in according to the PIX

Configuring IKE
When you design the VPN topology you will work out where the VPN end point is going to be. As we know by default the PIX will drop all traffic coming to a lower security level interface, which is where the VPN traffic will more than likely enter your network from; so we need to permit it. If you are using a VPN concentrator of some kind that is behind the PIX then you still need to permit the PIX to allow the VPN traffic to pass through it with an ACL.

IPSec/IKE/ISAKMP used the following ports & protocols:
IKE/ISAKMP = UDP port 500
Authentication Header (AH) = IP protocol number 51
Encapsulation Security Payload (ESP) = IP protocol number 50

So your ACL will take on the following syntax:

**For the remainder of this paper when entering a configuration anything in the ‘<>’ should be substituted with the relevant information specific to your configuration, i.e. an IP address, anything in the ‘[]’ is optional and will depend on your needs and configuration, the ‘|’ symbol means you have a choice of entering one of the commands that are either side of it ( this command|or this command) and anything with no symbols around it should be entered as shown**



If you do not know the remote peers IP address then use 0.0.0.0 for the IP address, this will usually be the case for remote access VPN’s.

A sample configuration would be:



Alternatively you can use the following command:



This command can be used in place of the above ACE’s however it allows all IPSec traffic to enter the PIX regardless of where it originates from, so use it with caution.

Authentication
Now we have allowed the IPSec traffic in to the network we need to configure how we will authenticate a remote peer, there are two options for site-to-site VPN’s; Pre-Shared Keys and Digital Certificates.
If you are a mid to large sized organization you may very well have a security policy which states exactly what authentication, encryption and hashing policies you should use, if you are a smaller company you will probably have to make this decision for yourself.
I won’t make any recommendations here as it will depend on your organizations needs.

First off we need to enable IKE on the PIX, we do this in the same way any service is activated on most Cisco equipment, with the keyword ‘enable’.



The above command speaks for itself; we have enabled IKE on the outside interface.

Obviously for the PIX to authenticate a remote peer we need to define it first, for this we can use an IP address or a host name providing the name has been configured first on the PIX. If you want to use a host name you will need to tell the PIX this with the following command (I find it good practise to always use this command before configuring any VPN’s to ensure the PIX is using the correct lookup method)



**Personally I always use the IP address method, as the host name either requires DNS (which is prone to spoofing) or a local hosts table.....either way it is still more configuration. If you do decide to use host names then substitute anything saying <remote peers IP address> with the relevant host name in the forthcoming configurations.**

Once we have told the PIX if we are using IP addresses or hostname for the remote peer we need to tell it the PSK we want to use to authenticate the remote peer with:



The subnet mask is optional and should be used if you are configuring a range of peers on the same subnet that will all use the same PSK. If you omit the subnet mask it will default to 255.255.255.255.

So an example configuration so far would be along the lines of:


That’s it for the PSK, all configured. The final think to say about PSK’s is that is you want all your VPN peers to use the same PSK then you can use 0.0.0.0 as the IP address to prevent having to enter a PSK and IP address for each peer; obviously this means if your PSK ever gets compromised then all of your VPN’s will also be compromised.

Once we have done this we need to create the policies for IKE to use. There are five things we must decide on and they must match on both peers:

Authentication Method (PSK, Certificates)
Encryption Algorithm (3DES, AES etc)
Message Hash (SHA-1 or MD5)
Key exchange settings – Diffie-Hellman group 1, 2 or 5.
The SA lifetime in seconds (default of 86,400 seconds)

We know what the PIX can support, so after deciding on what is secure enough for you needs you can supplement the standard from one from the below configuration and number the policy accordingly:



As you can see from the above configuration we have created a policy and gave it the priority number of 10, within this policy we have included 3DES as the encryption standard to use, MD5 as the hashing standard, group 2 for the Diffie-Hellman group and the SA has a lifetime of 84,600 seconds (one day), we are using a PSK for peer authentication for the peer with the IP address of 80.80.80.80 and the PSK is ‘qwertyuiop’.

This policy must exactly match the remote peers policy but it does not have to have the same priority number. As multiple policies can be configured on the peers due to the fact there may be more than one VPN on this host, the PIX will start with the first policy in the list (lowest priority number) and trawl through them all until a match is found; so this could easily be policy 60 and it will still work providing the algorithms in use are identical. For this reason it is considered best practise to put you r stronger policies at the top of the list.

That is IKE phase one configured on the firewall to use Pre-Shared keys. If you want to use certificates there is a lot more configuration involved but the added security should be considered a more than good enough trade-off.

Certificates
Personally I would say that if your knowledge of VPN’s, Certificates and configuring the PIX is relatively small AND if your security needs allow it, stay away from certificates and use PSK’s (not everyone will agree with this though ) as if you do not have a solid understanding of it then it can become a very daunting task very quickly.

Currently the PIX will support the following Certificate Authorities (CA’s):

Microsoft Windows Certificate Services (internal PKI)
VeriSign
Baltimore Technologies
Entrust Technologies

There are a few things that need to be configured on the PIX before it can use Certificates. Set the date and time, create your own RSA keys and make sure you have enough memory to store the certificates.

Set the date and time
Use the following command to set the correct date and time on the PIX:



So it would be something like:



If you do not have the correct date and time set you will run in to problems with any certificates you have on the PIX as all digital certificates have a valid from and a valid to date and time on them.

You should use the same settings that are on your CA to avoid any issues with the certificates you receive from it.

Set the host name and domain
Every IPSec device in the chain needs a unique identity, as we know the PIX can be configured with a Fully Qualified Domain Name (FQDN):



Check memory space
When using certificates the PIX will need to store the following in Flash:

RSA Public and Private Keys
PIX’s certificate issued to it by a CA
CA’s certificate ( and an RA’s certificate if one is used)
CRL (will have two CRL’s if an RA is being used)

Use the “show flashfs” command to view the amount of space available in Flash.

Create the RSA keys for the PIX to use
Here is where it all starts to get somewhat complicated...
After you have configured the time, date and FQDN of the PIX you need to generate your own RSA keys. RSA keys are used to create a digital signature for the certificate belonging to the PIX and to also verify the signature that is on the certificate.

When you create the keys you will have a public key and a private key, you may view the public key but there is no way for anyone, including the PIX administrator, to ever view the private key of the PIX.

To create the keys use the following syntax:



The ‘key’ switch will generate a single public and private key combination which are known as General Purpose keys, the ‘specialkey’ switch creates two sets of keys that are used for General Purpose and Encryption reasons.
The <modulus of the key> option is a value between 512 and 2048 and defines the bit size of the key, the higher this number the more secure the keys will be but the longer it will take to process.

To view the newly created keys use the following command:



**Remember you can not view your private key**

So, now we are ready to connect to a CA and retrieve its certificate.

Obtain CA’s Certificate
Before you go any further you should check with your certificate administrator (if you have one) and obtain some details from him:

Fully Qualified Domain Name (FQDN) of the CA (if external)
IP Address of the CA
The CGI-BIN script location (optional)
If the CA supports an LDAP server
If a registration Authority (RA) is in use

You won’t need all of the above information as there is more than one way to configure it depending on your setup.



If you have a CA administrator I would personally email him this configuration and ask him to fill in the blanks, however if you don’t have one here is the breakdown of it:

The first command ‘identity <CA name> <IP Address of the CA> [:ca script location] [LDAP IP Address]’ is pretty straight forward, it tells the PIX the FQDN and the IP address of the CA (you need to specify both for an external CA, however you can make do with just the actual CA’s name if it is internal)
The ‘:ca script location’ is optional and specifies the issuing script location is stored on the CA. The ‘LDAP IP Address’ is again optional and only needs to be entered if the CA uses an LDAP server for authentication.

A complete configuration for the first part could resemble this for Windows 2000 that does not need an LDAP server:



The second command ‘ca configure <CA name>’ speaks for itself, the ‘ca|ra’ allows you to tell the pix if it is a Certificate Authority or a Registration Authority, the <retry period> tells the PIX how often in minutes it should try to connect to the CA/RA and can be any value from between 0 – 60 minutes (1 is the default if nothing is entered) , the <retry count> states how many times the PIX can try to contact the CA during the establishment of the session and is a value between 0 – 100 with 0 being the default if nothing is entered (unlimited).

Finally the ‘crloptional’ tells the PIX whether it should continue to trust a previously issued certificate from the CA when the connection gets rebuilt, in other words in stead of going through the process of checking the remote peers certificate it will simply check the CRL to see if the previous one has been revoked, which is much quicker. If the CRL is not available and you have not used the ‘crloptional’ command then the PIX will not continue with the IPSec session as authentication will fail.

The first two commands deal with accessing the CA; the last command ‘ca authenticate <CA name>’ downloads the CA’s certificate. You must use the same CA name that you used in the ‘CA identity’. Optionally you can include the fingerprint of the CA and the PIX will automatically verify the certificate once it is downloaded, otherwise you will have to do it yourself.

So, we have told the PIX where to find the CA, how to access it and we have downloaded the CA’s certificate so we now trust the CA and can talk to it via encrypted means. The next step is to have the CA issue the PIX with a certificate so we can use it for authentication means when setting up an IPSec session.

To do this we use the following command:



The first part of this is self explanatory and tells the PIX to go to the CA and enroll (ask for) a certificate.
The <challenge password> is a password that can be up to 80 characters long and is alphanumeric. This is used if you ever want to revoke the certificate you just received and maybe asked for by your CA administrator. The CA can also use this to verify the identity of the requester of the certificate. If you don’t want to use a password you can use either the serial number of the PIX by using the ‘[serial]’ command, or you can use the IP Address of the PIX with the ‘[ipaddress]’ command instead, you can specify both if you so wish. Cisco recommend you use a password.

To verify you have received a certificate use the following command:



**CA’s are usually configured to require the manual approval of the CA Administrator before a certificate is issued. If this is the case you will have to wait for the CA admin to view your request and then approve it before your certificate is issued.**

Certificate information is not saved with the ‘wr mem’ command and you will need to use the ‘ca save all’ command to save your certificate information, key pairs etc:



**In the unlucky occurrence of your private key becoming compromised you can remove the existing public and private keys with the ‘ca zeroize rsa’ command. You will also need to revioke the relevant certificate and request a new one. Likewise if you install a new CA or change the existing one for any reason you can remove the configuration stored in flash with the ‘no ca identity’ command – if you do this you will have to configure a whole new CA and obtain a new certificate from it.**

So an example configuration so far (without the IPSec and ACL configuration) that uses a certificate and not a PSK would be:



Obviously you will need to NAT your CA and allow the remote peer access to it on port 80 for it to be able to authenticate to it

Configuring IKE phase two
Now we have configured all the parameters for IKE phase one whether using a PSK or Certificate for authentication, we need to configure the IPSec part of it.

We start off by telling the PIX what traffic we want it to encrypt using the policies we have defined. As always when we want to identity a certain type of traffic coming through the PIX we use an ACL, commonly know as a crypto ACL or cACL for short.

In the Crypto ACL we use the PERMIT statement to say that we DO want the traffic encrypted and the DENY statement to say what traffic we DON’T want the PIX to encrypt. Don’t confuse this ACL with a filtering ACL which will block or allow traffic, the cACL only informs the PIX if the traffic needs to be encrypted or not, it does not block or allow any traffic.
However just to confuse the issue a tad because of the nature of a VPN this cACL has a knock on effect to certain traffic depending on what interface it comes in on.

1.Outbound traffic that does not match a permit statement in the cACL will not be protected (encrypted)
2.Outbound traffic permitted in the cACL will be protected
3.Inbound traffic that is permitted in the cACL but is not protected will be dropped (remember incoming traffic from a VPN peer is expected to be encrypted, if it is not then there is something not right with it so the PIX will drop the traffic)
4.Inbound traffic that is protected but does not match the cACL will be processed normally in case the VPN end point in internal to the network.
5.Inbound traffic that is permitted and arrives protected will be processed in accordance with the policies configured for it, if the HASH check fails or the PIX is unable to decrypt it the traffic will be dropped.
6.Inbound unprotected traffic that does not match any cACL will be processed normally

You can have more than one cACL if your security needs require it.



The above cACL will protect (encrypt) any traffic from 192.168.10.0\24 that is destined to 192.168.20.0\24. Remember a permit statement in an ACL by default denies anything else that is not explicitly permitted.

The last thing we need to do with this cACL is tell the PIX to not perform Nat on any of the traffic we want to protect, else the VPN peer will drop the packets. We do this with the nat 0 command:



Now we have told the PIX what traffic we want it to protect, we need to tell it what policies to use to actually encrypt it with, just like we done with the IKE phase one configuration. We do this with what is known as a Transforms, which are collectively know as Transform Sets.

Transform Sets

An IPSec SA, just like the IKE SA need to agree on a set of rules (which are called transforms when we are talking about IKE phase two) to follow to encrypt and verify the traffic it is sending and receiving.

The PIX can support the following transforms:

Ah-md5-hmac - Used for Authentication
ah-sha-hmac – User for Authentication
esp-null – ESP transform that does not provide encryption
esp-des – ESP transform that used DES for encryption (56 bit)
esp-3des – ESP transform that uses 3DES for encryption (168 bit)
esp-aes – ESP transform using AES encryption (128 bit)
esp-aes-192 – ESP transform using AES-192 encryption (192 bit)
esp-aes-256 – ESP transform using AES-256 encryption (256 bit)
esp-md5-hmac – ESP transform with HMAC – MD5 authentication and is used with ESP-DES or ESP-3DES to provide extra integrity for ESP packets
esp-sha-md5 – ESP transform with HMAC-SHA authentication, used with ESP-DES or ESP-3DES for additional integrity for ESP packets.

**HMAC is outline in RFC 2104 and represents Keyed-Hashing for message authentication.**

Obviously the larger key sets you opt for the more processing power you will use and the longer the data-flow will take.

Once you have decided on a transform set, the syntax for configuring it is as follows:



The transforms 2 & 3 are optional. The PIX will search through all configured transform sets until it finds a suitable match.

So it could be something like so:



So I am using esp-3des for encryption and esp-md5-hmac for authentication

Next we need to specify the connection type; either tunnel or transport. Usually tunnel is used for site-to-site VPN’s (and is the default):



So now the transform set called STRONGEST is using es-3des for encryption, esp-md5-hmac for authentication and tunnel mode for the connection.

Now we have told it what standards to use to create a tunnel, we need to tell it how long the tunnel can be active for. This can be defined in either seconds or kilobytes:



OR



The default for kilobytes is 4,608,000 and the default for seconds is 28,800 (8 hours). The idea is to force a key exchange before the minimum amount of encrypted data needed to crack your encryption key can be gathered.
It is hard to say what this minimum is due to the ever changing state of technology as bigger and better CPU’s come out the lower the theoretical minimum amount of data needed becomes. I usually leave them to their defaults, unless extra security is needed then I lower them, in no case do I increase them.
Once the PIX has reached to within either 30 seconds of the maximum lifetime or to within 256KB of it the negotiation begins to setup a new connection. The ‘change over’ of connections should be seamless and no adverse effects should be experienced by any users.

Now we have all this information we need to link it all together and assign it to a specific VPN connection. We do this with Crypto Maps.

Crypto Maps
A crypto map simply ties in together all the necessary information to allow the PIX to setup the IPSec SA. You could think of it as the equivalent to the ‘isakmp policy’ command when configuring IKE phase one.

There are normally five crypto map commands we need to configure for the IPSec part to work. When you string these five entries together you will have a complete basic IPSec configuration.

First as always you need to give the crypto map a name and tell the PIX what to use it for:



The <map name> speaks for itself, the sequence number is the equivalent to the priority number when configuring the isakmp part earlier and ipsec-isakmp tell the PIX to use IKE to setup the IPSec connection.



We then need to tie in the ACL we configured earlier to inform the PIX which traffic to protect:



We obviously use the same name and sequence number and tell it to match address (the IP address) to what is defined in the ACL.



So now the PIX will follow the rules about protecting traffic I mentioned earlier in the Crypto ACL section.

Now we need to tell it which transform set to use:



Again use the same map name and sequence number, then just change <transform set name> for the name of the transform set you have created.



We need to tell the PIX which VPN peer we want to apply this crypto map to when it tries to establish an SA.



Enter the IP address of the remote peer that we are going to set the VPN tunnel up with.



Lastly we need to bind the crypto map to an interface, which is very straight forward:



Replace ‘outside’ with the relevant interface if needed.

And that is it for configuring Site-to-Site VPN’s.
I will sum it all up with two sample configurations, one with CA and one with a PSK:

PSK



Certificates



In this configuration I have NAT’ed the CA server (192.168.10.10 to the external IP of 80.80.80.90 and allowed connections on port 80 for certificate authentication reasons. The internal IP is included in the ‘protect’ ACL so IPSec traffic can reach it internally but the Peer can also reach it via it’s global address when needed before the IPSec connection is established.

Troubleshooting
Troubleshooting VPN’s can be an absolute nightmare at time, but nearly always come down to the configurations not matching on both peers.
First check if you can ping the remote peer – the other firewall admin may have disabled ICMP and you may need to ask him to enable it temporarily.

Once your ping has been successful, the following ‘show’ commands will show you all of your VPN configuration:

Show isakmp
Show isakmp policy
Show access-list
show crypto map
Show cryptoipsectransform-set
Show crypto ipsec security-association lifetime
Show crypto isakmp sa
Show crypto ipsec sa

By comparing the results of the above command(s) on both VP end points you should be able to narrow down your miss configuration.

Check the PSK’s are identical and the remote peer’s IP address and subnet mask are correct.
Check you have enabled IKE
Check the relevant traffic is being protected
Check you are not NAT’ing the protected traffic
AND check your configurations are identical!

The final step in troubleshooting VPN’s is to debug the entire VPN and watch the tunnel forming in real time (this is process heavy so conduct it during periods of low activity)

Debug crypto isakmp
Debug crypto ipsec

The commands speak for themselves and will allow you to see either the isakmp negotiation taking place, or the IPSec association, depending on which command you use.



The next paper will be on the ADSM.

That was in depth. Well written - But I have one question. Maybe this should be in a new thread (Move as you see fit)



Even if someone managed to spoof the DNS server, how would they handle the IKE negotiation?

Hi Dino,

If you are using DNS instead of IP Addresses then the PIX has no choice but to trust the DNS reply it receives from its lookup. If the wrong request comes back that does not point to the correct IPSec Peers then the site-to-site VPN will fail....it could be considered a form of DoS attack as you won't have connectivity with the other LAN.

It would also be possible for a very skilled attacker to corrupt the DNS replies to both end points and place himself in the middle of the IKE exchange, if you are using certificates you would be in big trouble now as some implementations of IPSec or IKE to be specific only require the name of the CA to be checked and not the peer who has the certificate.....so you can fool the peer into validating a certificate you own........which then means the remote IPSec peer becomes you....

If you are using a PSK a similar issue can arise. If you look at the VPN configuration the PIX is told to associate a PSK with an IP Address, not a user name or anything that can't easily be spoofed, yet obviously the IP address can be spoofed or even DNS can be spoofed to fool it if you are using the DNS method.

Shit I never thought of that.
Thanks buddy

I double checked my settings, but since I use a cisco concentrator, instead of the VPN application on the PIX, I'm pretty immune from man in the middle attacks.

But I do setup VPN tunnels for clients every now and then and I always used DNS. (Made life easier) - Oops