IPSec VPN tunnels can also be configured
using GRE (Generic Routing Encapsulation) Tunnels with IPsec
encryption. GRE tunnels greatly simply the configuration and
administration of VPN tunnels and are covered in our Configuring Point-to-Point GRE VPN Tunnels
article. Lastly, DMVPNs – a new VPN trend that provide outstanding
flexibility and almost no administration overhead can also be examined
by reading our Understanding Cisco Dynamic Multipoint VPN (DMVPN), Dynamic Multipoint VPN (DMVPN) Deployment Models & Architectures and Configuring Cisco Dynamic Multipoint VPN (DMVPN) - Hub, Spokes , mGRE Protection and Routing - DMVPN Configuration articles.
ISAKMP (Internet Security Association and Key Management Protocol) and IPSec
are essential to building and encrypting the VPN tunnel. ISAKMP, also
called IKE (Internet Key Exchange), is the negotiation protocol that
allows two hosts to agree on how to build an IPsec security association.
ISAKMP negotiation consists of two phases: Phase 1 and Phase 2.
Phase 1 creates the first tunnel, which
protects later ISAKMP negotiation messages. Phase 2 creates the tunnel
that protects data. IPSec then comes into play to encrypt the data
using encryption algorithms and provides authentication, encryption and
anti-replay services.
IPSec VPN Requirements
To help make this an easy-to-follow
exercise, we have split it into two required steps to get the
Site-to-Site IPSec Dynamic IP Endpoint VPN Tunnel to work.
These steps are:
(1) Configure ISAKMP (ISAKMP Phase 1)
(2) Configure IPSec (ISAKMP Phase 2, ACLs, Crypto MAP)
Our example setup consists of the headquarter router R1 which is assigned a static public IP address, and two remote routers, R2 & R3. Both remote routers (R2 & R3) connect to the Internet and have a dynamic public IP address assigned by the ISP, as shown in the diagram below:
Our Headquarters is assigned an internal network of 10.10.10.0/24, while Remote Site 1 has been assigned network 20.20.20.0/24. and Remote Site 2 network 30.30.30.0/24. The goal is to securely connect both remote sites with our headquarters and allow full communication, without any restrictions.
Configure ISAKMP (IKE) - (ISAKMP Phase 1)
IKE exists only to establish SAs
(Security Association) for IPsec. Before it can do this, IKE must
negotiate an SA (an ISAKMP SA) relationship with the peer.
To begin, we’ll start working on the Headquarter router (R1).
First step is to configure an ISAKMP Phase 1 policy:
#crypto isakmp policy 1
#encr 3des
#hash md5
#authentication pre-share
#group 2
#lifetime 86400
3DES - The encryption method to be used for Phase 1.
MD5 - The hashing algorithm
Pre-share - Use Pre-shared key as the authentication method
Group 2 - Diffie-Hellman group to be used
86400 – Session key
lifetime. Expressed in either kilobytes (after x-amount of traffic,
change the key) or seconds. Value set is the default value.
We should note that ISAKMP Phase 1
policy is defined globally. This means that if we have five different
remote sites and configured five different ISAKMP Phase 1 policies (one
for each remote router), when our router tries to negotiate a VPN tunnel
with each site it will send all five policies and use the first match
that is accepted by both ends. Since we only have one ISAKMP policy,
this will be used for all remote VPN routers.
Next we are going to define a pre-shared
key for authentication with our peers (R2 & R3 routers) by using
the following command:
#crypto isakmp key firewallcx address 0.0.0.0 0.0.0.0
The peers pre-shared key is set to firewallcx and note that we are defining a remote public IP address of 0.0.0.0 0.0.0.0. This tells our headquarter router that the remote routers have dynamic public IP addresses and ensures it will try to negotiate and establish a VPN tunnel with any router that requests it.
Configure IPSec
To configure IPSec we need to setup the following in order:
- Create extended ACL
- Create IPSec Transform
- Create Dynamic Crypto Maps
- Apply crypto map to the public interface
Let us examine each of the above steps.
Let us examine each of the above steps.
Creating Extended ACL
Next step is to create an access-list
and define the traffic we would like the router to pass through each
VPN tunnel. In this example, for the first VPN tunnel it would be
traffic from headquarters (10.10.10.0/24) to remote site 1
(20.20.20.0/24) and for the second VPN tunnel it will be from our
headquarters (10.10.10.0/24) to remote site 2 (30.30.30.0/24).
Access-lists that define VPN traffic are sometimes called
#crypto access-list or interesting traffic access-list.
#crypto access-list or interesting traffic access-list.
Because we are dealing with two separate VPN tunnels, we’ll need to create one set of access-lists for each:
#ip access-list extended VPN1-TRAFFIC
# permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
!
#ip access-list extended VPN2-TRAFFIC
#permit ip 10.10.10.0 0.0.0.255 30.30.30.0 0.0.0.255
Create IPSec Transform (ISAKMP Phase 2 policy)
Now we need to create the transform set used to protect our data. We’ve named our transform set TS:
#crypto ipsec transform-set TS esp-3des esp-md5-hmac
The above command defines the following:
- ESP-3DES - Encryption method
- MD5 - Hashing algorithm
Create Dynamic Crypto Maps
The Crypto Map is the
last step of our setup and connects the previously defined ISAKMP and
IPSec configuration together. We will need one dynamic crypto map for
each remote endpoint, which means a total of two crypto maps for our
setup.
First we create a crypto map named VPN
which will be applied to the public interface of our headquarter
router, and connect it with the dynamic crypto maps we named as hq-vpn.
#crypto map VPN 1 ipsec-isakmp dynamic hq-vpn
The ipsec-isakmp tag
tells the router that this crypto map is an IPsec crypto map. Now we
create our two dynamic crypto maps using the following configuration
commands:
#crypto dynamic-map hq-vpn 10
#set security-association lifetime seconds 86400
#set transform-set TS
#match address VPN1-TRAFFIC
#crypto dynamic-map hq-vpn 11
#set security-association lifetime seconds 86400
#set transform-set TS
#match address VPN2-TRAFFIC
Adding additional remote sites in the
future is as easy as simply adding more dynamic crypto maps,
incrementing the index number and specifying the match address extended
access-lists for each remote network.
Apply Crypto Map to the Public Interface
The final step is to apply our crypto
map to the public interface of the headquarter router, which is
FastEthernet0/1. In many cases, this might be a serial or ATM (ADSL -
Dialer) interface:
#interface FastEthernet0/1
#crypto map VPN
#crypto map VPN
Note that you can assign only one crypto map to an interface.
As soon as we apply crypto map on the interface, we receive a message from the router that confirms isakmp is on: “ISAKMP is ON”.
At this point, we have completed the
IPSec VPN configuration on our headquarter router and we can move to the
remote endpoint routers.
Configuring Remote Endpoint Routers (Dynamic Public IP Addresses)
Our remote routers connect to the
Internet and are assigned a dynamic IP address which changes
periodically by the ISP. In most part, the configuration is similar to
that of the headquarter router, but with a few minor changes.
In the configuration below, IP address 74.200.90.5 represents the public IP address of our headquarter router.
Remote Site 1 Router
#crypto isakmp policy 1
#encr 3des
#encr 3des
#hash md5
#authentication pre-share
#group 2
#lifetime 86400
!
#crypto isakmp key firewallcx address 74.200.90.5
!
#ip access-list extended VPN-TRAFFIC
# permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
!
#crypto ipsec transform-set TS esp-3des esp-md5-hmac
!
#crypto map vpn-to-hq 10 ipsec-isakmp
#set peer 74.200.90.5
#set transform-set TS
#match address VPN-TRAFFIC
!
!
#interface FastEthernet0/1
#crypto map vpn-to-hq
Remote Site 2 Router
#crypto isakmp policy 1
#encr 3des
#hash md5
#authentication pre-share
#group 2
#lifetime 86400
!
#crypto isakmp key firewallcx address 74.200.90.5
!
#ip access-list extended VPN-TRAFFIC
#permit ip 30.30.30.0 0.0.0.255 10.10.10.0 0.0.0.255
!
#crypto ipsec transform-set TS esp-3des esp-md5-hmac
!
#crypto map vpn-to-hq 10 ipsec-isakmp
#set peer 74.200.90.5
#set transform-set TS
#match address VPN-TRAFFIC
!
#interface FastEthernet0/1
# crypto map vpn-to-hq
It is noticeable that the only major difference between the two routers configuration is the extended access list.
Network Address Translation (NAT) and IPSec VPN Tunnels
Network Address Translation (NAT) is
most likely to be configured to provide Internet access to internal
hosts. When configuring a Site-to-Site VPN tunnel, it is imperative to
instruct the router not to perform NAT (deny NAT) on packets destined to the remote VPN networks.
This is easily done by inserting a deny statement at the beginning of the NAT access lists as shown below:
For the headquarter router, deny NAT for packets destined to the remote VPN networks, but allow NAT for all other networks (Internet):
ip nat inside source list 100 interface fastethernet0/1 overload!
access-list 100 remark -=[Define NAT Service]=-
access-list 100 deny ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
access-list 100 deny ip 10.10.10.0 0.0.0.255 30.30.30.0 0.0.0.255
access-list 100 permit ip 10.10.10.0 0.0.0.255 any
access-list 100 remark
access-list 100 remark -=[Define NAT Service]=-
access-list 100 deny ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
access-list 100 deny ip 10.10.10.0 0.0.0.255 30.30.30.0 0.0.0.255
access-list 100 permit ip 10.10.10.0 0.0.0.255 any
access-list 100 remark
For Remote Site 1 Router, deny NAT for packets destined to the headquarter network:
ip nat inside source list 100 interface fastethernet0/1 overload
!
access-list 100 remark -=[Define NAT Service]=-
access-list 100 deny ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
access-list 100 permit ip 20.20.20.0 0.0.0.255 any
access-list 100 remark
For Remote Site 2 Router, deny NAT for packets destined to the headquarter network:
ip nat inside source list 100 interface fastethernet0/1 overload
!
access-list 100 remark -=[Define NAT Service]=-
access-list 100 deny ip 30.30.30.0 0.0.0.255 10.10.10.0 0.0.0.255
access-list 100 permit ip 30.30.30.0 0.0.0.255 any
access-list 100 remark
Bringing Up and Verifying the VPN Tunnel
At this point, we’ve completed our
configuration and the VPN Tunnel is ready to be brought up. To initiate
the VPN Tunnel, we need to force one packet to traverse the VPN and
this can be achieved by pinging from one router to another. There is
however one caveat that was mentioned in the beginning of this article:
Site to Site VPN networks with Dynamic remote Public IP addresses can only be brought up by the remote sites.
The reason for this is simple and
logical. Only the remote site routers are aware of the headquarter’s
public IP address (74.200.90.5) because it is static, and therefore only
the remote router can initiate the VPN tunnel.
From Remote Site 1, let’s ping the headquarter router:
R2# ping 10.10.10.1 source fastethernet0/1Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 73.54.120.100
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 42/46/5The first ping received a timeout, but the rest received a reply, as expected. The time required to bring up the VPN Tunnel is sometimes slightly more than 2 seconds, causing the first ping to timeout.
To verify the VPN Tunnel, use the show crypto session command:
R2# show crypto session
Crypto session current status
Interface: FastEthernet0/1
Session status: UP-ACTIVE
Peer: 74.200.90.5 port 500
IKE SA: local 73.54.120.100/500 remote 74.200.90.5 /500 Active
IPSEC FLOW: permit ip 20.20.20.0/255.255.255.0 10.10.10.0/255.255.255.0
Active SAs: 2, origin: crypto map
From Remote Site 2, let’s ping the headquarter router:
R3# ping 10.10.10.1 source fastethernet0/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
Packet sent with a source address of 85.100.120.5
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 47/50/53 ms
To verify the VPN Tunnel, use the show crypto session command:
R3# show crypto session
Crypto session current status
Interface: FastEthernet0/1
Session status: UP-ACTIVE
Peer: 74.200.90.5 port 500
IKE SA: local 85.100.120.5/500 remote 74.200.90.5 /500 Active
IPSEC FLOW: permit ip 30.30.30.0/255.255.255.0 10.10.10.0/255.255.255.0
Active SAs: 2, origin: crypto map
