CISCO
PIX: CONFIGURING SITE TO SITE VPN'S
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:
Original Tutorial
by nokia for TheTAZZone-TAZForum
Originally posted on January 30th, 2007 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.