VPN With Pre-Shared Keys

By Cisco Press | Oct 30, 2001 | Print this Page
http://www.enterprisenetworkingplanet.com/netsecur/article.php/913361/VPN-With-PreShared-Keys.htm

Cisco Secure Internet Security Solutions - Chapter 4
by Andrew Mason, Mark Newcomb

Cisco Secure PIX Firewall - Part 9
VPN with Preshared Keys

Cisco Secure Internet Security Solutions - click to go to publisher's site

Using preshared keys is easy, once you understand the concepts presented in the previous example. The difference between this configuration and the previous one is that you are now relying on the Internet Security Association and Key Management Protocol (ISAKMP) for exchanging keys. This section presents the configuration before exploring how it has changed. The main office's configuration is as follows:

 hostname chicago
 domain-name bigcompany.com
 isakmp enable outside
 isakmp policy 15 authentication pre-share
 isakmp policy 15 encr 3des
 crypto isakmp key isakmpkey address 172.30.1.2
 crypto ipsec transform-set strong esp-sha-hmac esp-3des
 access-list myaccesslist permit ip 10.1.2.0 255.255.255.0
 crypto map seattletraffic 29 ipsec-isakmp
 crypto map seattletraffic 29 match address myaccesslist
 crypto map seattletraffic 29 set transform-set strong
 crypto map seattletraffic 29 set peer 172.30.1.2
 crypto map seattletraffic interface outside
 sysopt connection permit-ipsec
The branch PIX Firewall configuration looks like this:
 hostname seattle
 domain-name bigcompany.com
 isakmp enable outside
 isakmp policy 21 authentication pre-share
 isakmp policy 21 encryption 3des
 crypto isakmp key isakmpkey address 172.30.1.1
 crypto ipsec transform-set strong esp-3des esp-sha-hmac
 access-list chicagolist permit ip 10.1.1.0 255.255.255.0
 crypto map chicagotraffic 31 ipsec-isakmp
 crypto map chicagotraffic 31 match address chicagolist
 crypto map chicagotraffic 31 set transform-set strong
 crypto map chicagotraffic 31 set peer 172.30.1.1
 crypto map chicagotraffic interface outside
 sysopt connection permit-ipsec

isakmp Commands
Before explaining the example, review Table 4-8 concerning the isakmp commands. The isakmp commands are very similar in syntax to the vpdn commands. As with most commands, using the no form of the command removes the configuration.

Table 4-8: isakmp Commands
`
CommandDescription
isakmp client configuration address-pool local localpoolname This command assigns a VPN client an address from within the addresses set aside by the ip local pool command.
isakmp enable interfacenameThis enables ISAKMP on the interface specified by the parameter interfacename.
isakmp identity address | hostnameThis identifies the system for IKE participation.
isakmp key keystring address peer-address The keystring specifies the preshared key. The peer-address specifies the IP address of the peer.
isakmp peer fqdn fqdn no-xauth no-configmode

The fqdn (fully qualified domain name) is the full DNS name of the peer. This is used to identify a peer that is a security gateway.

The no-xauth option is to used if you enabled the Xauth feature and you have an IPSec peer that is a gateway.

The no-config-mode option is used if you enabled the IKE Mode Configuration feature and you have an IPSec peer that is a security gateway.

isakmp policy priority authentication preshare | rsa-sigThis sets the priority for the authentication and defines whether you are using pre-shared keys or RSA signatures.
isakmp policy priority group1 | group2group1 and group2 are optionally used to specify whether a 768-bit Diffie-Hillman /prime modulus group (group1) or a 1024-bit Diffie-Hillman prime modulus group (group2) will be used on new exchanges.
isakmp policy priority hash md5 | shaSpecifies MD5 or SHA as the hash algorithm to be used in the IKE policy.
isakmp policy priority lifetime secondsSpecifies how many seconds each SA should exist before expiring.

Explanation of VPN with Preshared Keys
Going back to the configuration, you can see that it is really quite simple to enable preshared keys. The following section will walk you through the configuration and explain what has been configured.

First, set the host name. The fully qualified domain name (FQDN) is set with the domain-name command.

 hostname chicago
 domain-name bigcompany.com
Then set ISAKMP to the outside interface and define that you use preshared keys and 3DES encryption.
 isakmp enable outside
 isakmp policy 15 authentication pre-share
 isakmp policy 15 encr 3des
The ISAKMP key, whose value is isakampkey, is set, along with the IP address of the outside interface of the peer. Then set transform-set to first use esp-sha-hmac and then esp-3des.
 crypto ipsec transform-set strong esp-sha-hmac esp-3des
Define an access list for use with the crypto map command, setting the permitted IP addresses to match the remote site's IP address.
 access-list myaccesslist permit ip 10.1.2.0 255.255.255.0
Next, map the traffic to be encrypted, set the peer, and set the interface.
 crypto map seattletraffic 29 ipsec-isakmp
 crypto map seattletraffic 29 match address myaccesslist
 crypto map seattletraffic 29 set transform-set strong
 crypto map seattletraffic 29 set peer 172.30.1.2
 crypto map seattletraffic interface outside
Finally, set the PIX to allow IPSec traffic through the interfaces.
 sysopt connection permit-ipsec
The only real differences between the branch office and the main office configurations are that the peers are set to the other office's PIX outside interface, and the traffic to be encrypted is set to the other office's LAN.

Obtaining Certificate Authorities (CAs)
Retrieving certificate authorities (CAs) with the PIX Firewall uses almost exactly the same method as that used on routers. The following are the commands used to obtain a CA. Note that these commands might not show in a configuration. The administrator should avoid rebooting the PIX during this sequence. The steps are explained as they are shown.

First, define your identity and the IP address of the interface to be used for the CA. Also configure the timeout of retries used to gain the certificate and the number of retries.

 ca identity bigcompany.com 172.30.1.1
 ca configure bigcompany.com ca 2 100>
Generate the RSA key used for this certificate.
 ca generate rsa key 512
Then get the public key and certificate.
 ca authenticate bigcompany.com
Next, request the certificate, and finally, save the configuration.
 ca enroll bigcompany.com enrollpassword
 ca save all
At this point, you have saved your certificates to the flash memory and are able to use them. The configuration for using an existing CA is as follows:
 domain-name bigcompany.com
 isakmp enable outside
 isakmp policy 8 auth rsa-signature
 ca identity example.com 172.30.1.1
 ca generate rsa key 512
 access-list 60 permit ip 10.1.2.0 255.255.255.0
 crypto map chicagotraffic 20 ipsec-isakmp
 crypto map chicagotraffic 20 match address 60
 crypto map chicagotraffic 20 set transform-set strong
 crypto map chicagotraffic 20 set peer 172.30.1.2
 crypto map chicagotraffic interface outside
 sysopt connection permit-ipsec

PIX-to-PIX Configuration
One advantage of using the PIX Firewall is that it has become a standard within the industry. As time passes, your business might acquire or become acquired by another company. To provide connectivity, you are faced with two choices: enabling VPNs over the Internet or using dedicated connections. Because one of the benefits of the PIX box is to allow secure VPNs, this section explores how to set up two PIX Firewalls between different locations through the Internet.

In this scenario, shown in Figure 4-10, assume that both companies trust each other totally. This means that you will not filter any traffic between the sites, and all hosts on both sites will be able to see all hosts on the other site. The peers use ISAKMP in Phase 1 to negotiate an IPSec connection in Phase 2.

Figure 4-12 PIX-to-PIX IPSec with ISAKMP Example

(Click image for larger view in a new window)

As shown in Figure 4-12, the main office uses an internal IP address of 10.1.1.1/24 with an IP address of 172.30.1.1 on the outside interface. The branch office uses an internal IP address of 10.2.1.1/24 and an IP address of 172.30.2.1 on the outside interface. The following is the configuration for the PIX Firewall at the main office. After the configuration, you will see a discussion of the commands used.

 hostname mainofficepix
 nameif ethernet0 outside security0
 nameif ethernet1 inside security100
 interface ethernet0 auto
 interface ethernet1 auto
 mtu outside 1500
 mtu inside 1500
 ip address outside 172.30.1.1 255.255.255.0
 ip address inside 10.1.1.1 255.255.255.0
 access-list 100 permit ip 10.1.1.0 255.255.255.0 10.2.1.0 255.255.255.0
 nat (inside) 0 access-list 100
 sysopt connection permit-ipsec
 crypto ipsec transform-set maintransformset esp-des esp-md5-hmac
 crypto map mymap 10 ipsec-isakmp
 crypto map mymap 10 match address 100
 crypto map mymap 10 set peer 172.30.2.1
 crypto map mymap 10 set transform-set maintransformset
 crypto map mymap interface outside
 isakmp enable outside
 isakmp key mysharedkey address 172.30.2.1 netmask 255.255.255.255
 isakmp policy 10 authentication pre-share
 isakmp policy 10 encryption des
 isakmp policy 10 hash md5
 isakmp policy 10 group 1
 isakmp policy 10 lifetime 768
All of the preceding commands have been discussed previously within this chapter. There are only a few new items that you need to watch carefully to ensure that this configuration will work.

First, access list 100 must allow hosts from the branch office through the PIX Firewall. Limiting who is allowed through on the branch office network or which hosts that the branch office hosts are allowed to see is controlled through this access list. For example, assume that everyone except the branch manager in the branch office is allowed to connect only to the hosts at 10.1.1.14, 10.1.1.15, and 10.1.1.200. The branch manager, whose IP address is 10.2.1.53, is allowed to access all hosts on the main office network. In this case, your access list would be as follows:

 access-list 100 permit ip 10.1.1.0 255.255.255.0 10.1.2.1.53 255.255.255.255
 access-list 100 permit ip 10.1.1.14 255.255.255.255 10.2.1.0 255.255.255.0
 access-list 100 permit ip 10.1.1.15 255.255.255.255 10.2.1.0 255.255.255.0
 access-list 100 permit ip 10.1.1.200 255.255.255.255 10.2.1.0 255.255.255.0
Now take note of the use of the nat 0 command to prevent NAT from occurring. In some cases, you need to enable NAT because both sites are using the same nonroutable IP addresses. This is actually a common scenario. For example, without NAT enabled and both sites using the 10.1.1.0/24 network, both PIX Firewalls will not know which network to respond to when a packet is received.

Next, you set up the Phase 2 connection. Use the sysopt command with the permit-ipsec parameter to allow packets associated with this SA through the PIX Firewall. Set up the transform set for IPSec, assign a map to the access list, and set the interface for the crypto connection. You also use the crypto map command to set the peer for this connection. As always, the IP address of the peer should be the outside interface of the remote PIX Firewall.

As with any ISAKMP key exchange, you need to ensure that the interface chosen is appropriate, that the key is exactly the same on both peers, and that the encryption and hash types are identical between peers.

PIX-to-PIX with Identical Internal IP Addresses
One of the issues raised by using a nonroutable IP address is the use of the IP address while another connected location is using that same address. This is a common issue when two companies connect to each other for the first time. Looking at Figure 4-13, notice that both the main and branch offices use the same internal IP address. In this situation, you will need to translate the addresses of both internal networks.

Figure 4-13 PIX-to-PIX with Identical Internal Network Addresses

(Click image for larger view in a new window)

On the PIX at the main office, you will use NAT to translate all data destined for the branch office to the 192.168.1.0/24 network. The branch office translates all data destined for the main office to use 192.168.2.0/24 addresses. Therefore, from the point of view of the main office, the branch office appears to use 192.168.2.0/24. From the point of view of the branch office, the main office appears to use 192.168.1.0 as its internal IP addresses. Each PIX Firewall needs to be configured in a similar manner. Figure 4-14 shows how each office sees the other.

Figure 4-14 PIX-to-PIX with Each Side Using NAT

(Click image for larger view in a new window)

The listing of this configuration follows. This is virtually the same configuration as the previous example, with a few minor changes. First, you have to implement a global pool for use with NAT for data traveling to the branch office. Second, you have to remove the lines associated with the nat 0 command for data traveling to the branch office. Third, you have to create a new access list called nattobranch, which is used by NAT to change the source address of the packets so that these packets appear to originate from the 192.168.1.0/24 network.

 hostname mainofficepix
 nameif ethernet0 outside security0
 nameif ethernet1 inside security100
 interface ethernet0 auto
 interface ethernet1 auto
 mtu outside 1500
 mtu inside 1500
 ip address outside 172.30.1.1 255.255.255.0
 ip address inside 10.1.1.1 255.255.255.0
 global (outside) 1 192.168.1.1-192.168.1.253
 global (outside) 1 192.168.1.254
 access-list nattobranch permit ip 10.1.1.0 255.255.255.0 192.168.2.1 255.255.255.0
 nat (inside) 1 access-list nattobranch
 sysopt connection permit-ipsec
 crypto ipsec transform-set maintransformset esp-des esp-md5-hmac
 crypto map mymap 10 ipsec-isakmp
 crypto map mymap 10 match address nattobranch
 crypto map mymap 10 set peer 172.30.2.1
 crypto map mymap 10 set transform-set maintransformset
 crypto map mymap interface outside
 isakmp enable outside
 isakmp key mysharedkey address 172.30.2.1 netmask 255.255.255.255
 isakmp policy 10 authentication pre-share
 isakmp policy 10 encryption des
 isakmp policy 10 hash md5
 isakmp policy 10 group 1
 isakmp policy 10 lifetime 768

Cisco Secure Internet Security Solutions -- Click to go to publisher's site Summary
This chapter has shown how to configure the PIX Firewall in many different ways. It started with the most basic form before moving to a more realistic configuration. This realistic configuration, allowing users through to specific services, should prove adequate for most companies that do not require the use of a DMZ.

The chapter then moved on to explore using single and multiple DMZs, along with AAA services and other examples of connections possible with the PIX Firewall. These configurations provide examples that are applicable to larger organizations.