CISCO
PIX: CONFIGURING SITE TO SITE VPN'S CONT...
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**
Code:
London(config)# access-list <ACL name> permit udp <remote peer
IP address> <subnet mask> host <outside interface IP
address> eq isakmp
London(config)# access-list <ACL name> permit ah <remote peer
IP address> <subnet mask> host <outside interface IP
address>
London(config)# access-list <ACL name> permit esp <remote peer
IP address> <subnet mask> host <outside interface IP
address>
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:
Code:
London(config)# access-list <IKE> permit udp host
80.81.81.81 host 80.80.80.80 eq isakmp
London(config)# access-list <ACL name> permit host
80.81.81.81 host 80.80.80.80
London(config)# access-list <ACL name> permit esp host
80.81.81.81 host 80.80.80.80
Alternatively you can use the following command:
Code:
London(config)# sysopt connection permit-ipsec
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’.
Code:
London(config)# isakmp enable outside
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)
Code:
London(config)# isakmp identity < IP adderss|host name>
**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:
Code:
London(config)# isakmp key <Pre-Shared Key> address <remote
peers IP address> [<subnet mask>]
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:
Code:
London(config)# isakmp identity address
London(config)# isakmp key qwertyuiop address 80.80.80.80
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:
Code:
London(config)# isakmp enable outside
London(config)# isakmp identity address
London(config)# isakmp key qwertyuiop address 80.80.80.80 netmask
255.255.255.255
London(config)# isakmp policy 10 authentication pre-share
London(config)# isakmp policy 10 encryption 3des
London(config)# isakmp policy 10 group 2
London(config)# isakmp policy 10 hash md5
London(config)# isakmp policy 10 lifetime 86400
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:
Code:
London(config)# clock set
<hh:mm:ss><month><day><year>
So it would be something like:
Code:
London(config)# clock set 22:26:00 october 12 2006
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):
Code:
London(config)# hostname <name of PIX>
London(config)# domain-name <domain name of organisation>
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.
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.