CISCO
PIX: CONFIGURING SITE TO SITE VPN'S CONT...
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:
Code:
London(config)# ca generate rsa <key|specialkey< <modulus of
the key>
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:
Code:
show ca mypubkey rsa
**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.
Code:
London(config)# ca identity <CA name> <IP Address of the
CA> [:ca script location] [LDAP IP Address]
London(config)# ca configure <CA name ca|ra <retry period>
<retry count> [crloptional]
London(config)# ca authenticate <CA name> [fingerprint of the CA]
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:
Code:
London(config)# ca identity Certserver
192.168.10.10:/certserv/mscep/mscep.dll
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:
Code:
London (config)# ca enroll <CA name> <challenge password>
[serial] [ipaddress]
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:
Code:
London# show ca certificate
**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:
Code:
London(config)# ca save all
London (config)# wr mem
**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:
Code:
London(config)# ca identity Certserver
192.168.10.10:/certserv/mscep/mscep.dll
London(config)# ca configure Certserver ra 1 5 crloptional
London(config)# ca enroll Certserver abcdefg12345
London(config)# ca save all
London(config)# isakmp policy 10 authentication rsa-sig
London(config)#isakmp policy 10 encryption 3des
London(config)# isakmp policy 10 group 2
London(config)# isakmp policy 10 hash md5
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.
Code:
London(config)# access-list VPN_PROTECTED permit ip 192.168.10.0
255.255.255.0 192.168.20.0 255.255.255.0
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:
Code:
London(config)# nat (inside) 0 access-list VPN_PROTECTED
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:
Code:
London(config)# crypto ipsec transform-set <name of transform
-set> <transform 1> [[transform 2] [transform 3]]
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:
Code:
London(config)# crypto ipsec transform-set STRONGEST
esp-3des esp-md5-hmac
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):
Code:
London(config)# crypto ipsec transform-set STRONGEST mode tunnel
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:
Code:
London(config)# crypto ipsec security-association lifetime seconds 86400
OR
Code:
London(config)# crypto ipsec security-association lifetime kilobytes
4608000
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:
Code:
London(config)# crypto map <map name> <sequence number>
ipsec-isakmp
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.
Code:
London(config)# crypto map VPN 10 ipsec-isakmp
We then need to tie in the ACL we configured earlier to inform the PIX
which traffic to protect:
Code:
London(config)# crypto map <map name> <sequence
number>match address <ACL name>
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.
Code:
London(config)# crypto map VPN 10 match address VPN_PROTECTED
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:
Code:
London(config)# crypto map <map name> <sequence
number> set transform-set <transform set name>
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.
Code:
London(config)# crypto map VPN 10 set transform-set STRONGEST
We need to tell the PIX which VPN peer we want to apply this crypto map
to when it tries to establish an SA.
Code:
London(config)# crypto map <map name> <sequence number> set
peer <peer’s ip address>
Enter the IP address of the remote peer that we are going to set the
VPN tunnel up with.
Code:
London(config)# crypto map VPN 10 set peer 80.81.81.81
Lastly we need to bind the crypto map to an interface, which is very
straight forward:
Code:
London(config)# crypto map VPN 10 interface outside
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:
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.