Site to Site VPN with Dynamic Crypto
Map
Written By Harris Andrea
In this post I will talk about Hub-and-Spoke VPN with one dynamic and two
static crypto-maps between Cisco routers. The scenario is as following:
There is a central HQ site which will be the Hub of our VPN network and
also two branch sites which will be the spokes in our VPN network (see
diagram below). The central HQ site will have a dynamic crypto-map while
the branch sites will have a static crypto map. By configuring the central
site with a dynamic crypto-map it means that the remote branch sites can
have a dynamic public IP address. The branch sites will have a static
crypto-map because for them the remote site (i.e the central HQ site) will
have a static public IP address.
First of all let’s discuss some key points you must have in mind for this
scenario which uses both static crypto-map and Dynamic crypto-map.
● In the case of static crypto-map all peers on the VPN terminator (HUB)
must be configured manually with their specific static public IP address. In
the case of a dynamic crypto-map we don’t have to configure the peers
one-by-one on the VPN terminator (HUB). There are no changes on the
spoke sites, i.e. we leave static crypto-map as it was.
● In the case of dynamic crypto-map, the initiator of VPN session will be
only the spoke site. This means that if traffic doesn’t come from the Spoke
in the VPN tunnel, then VPN dynamic tunnel will not be established. When,
however, traffic is initiated from the spoke site (branch) then the VPN
tunnel will be established and the connection will be bidirectional between
branch and HQ.
● There is a simple configuration on the HUB site. If we add more
spokes, configuration will be done only on spoke site and there is no need
for changing anything on HUB.
Let’s set our LAB network diagram below.
Equipment used in This lab:
HQ – 3725 IOS c3725-advsecurityk9-mz.124-1c
Branches – 2691 IOS c2691-adventerprisek9-mz.123-17a
LAB Scenario:
We’ve got HQ office and two Branches, which are connected via Internet.
The Hosts in Branches must have secure access to the servers located in
HQ. That is, network subnets [Link]/24 and [Link]/24 must
have secure access to subnet [Link]/24. That’s an ordinary scenario,
which many organizations implement all over the world. Since this is a Lab
scenario, only private IP addresses were used. In a real scenario the WAN
IP addresses of HQ and Branches routers will be public IP.
Configuration:
The very first thing you need to do in such a scenario is to verify that all
sites have IP connectivity between them. Verify that all WAN interfaces of
routers can reach each other over the Internet.
Branches Configuration.
! Create isakmp policy. If you have multiple policies it is recommended that
the most strong policy should be first (i.e have the lowest policy number).
crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 2
MORE READING: Site-to-Site IPSEC VPN Between Two Cisco ASA - one with
Dynamic IP
! Configure crypto isakmp key. The keys between peers must be the same.
In our case the branches should specify the static IP address of HQ and
have the same key with HQ
crypto isakmp key somestrongkey address [Link]
! Configure IPsec transform-set. This specifies what encryption and Hash
algorithm should be used for encryption of VPN traffic.
crypto ipsec transform-set ts esp-aes 256 esp-sha-hmac
! Create access list by which we’ll match interesting traffic that will pass
through the VPN. In case of Branch 1 will be the following: if source is
[Link]/24 and destination is [Link]/24 then traffic will be
encrypted. Similarly for Branch 2, if source is [Link]/24 and
destination is [Link]/24 then traffic will be encrypted.
Branch 1 ACL:
ip access-list extended vpn
permit ip [Link] [Link] [Link] [Link]
Branch 2 ACL:
ip access-list extended vpn
permit ip [Link] [Link] [Link] [Link]
! Create crypto-map and snap to it the already created transform-set and
access list. Also indicate VPN peer and turn on Reverse-route. The
purpose of reverse-route is that when VPN tunnel is established,
Destination network of access list created for interesting traffic will be
added in routing table as static route. In our case this access list is “vpn”
and the destination network of this access list is [Link]/24.
crypto map vpn 10 ipsec-isakmp
set peer [Link]
set transform-set ts
match address vpn
reverse-route
!Assign crypto-map to external interface. In our case Fa0/0. After this,
ISAKMP will turn on.
interface FastEthernet0/0
crypto map vpn
Configuration of Branches is done. Let’s start HQ configuration.
HQ Configuration:
! crypto isakmp policy will not be changed.
crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 2
! All peer addresses are assigned with a secret key, i.e. all zeros are
assigned, for avoiding writing each branch’s IP address separately.
crypto isakmp key somestrongkey address [Link] [Link]
! IPSec Transform-set will not change.
crypto ipsec transform-set ts esp-aes 256 esp-sha-hmac
! Access list, by which interesting traffic is matched, will be changed.
Source will be [Link]/24 and destination will be [Link]/24 and
[Link]/24.
ip access-list extended vpn
permit ip [Link] [Link] [Link] [Link]
permit ip [Link] [Link] [Link] [Link]
! Configure Dynamic crypto-map. Assign the same parameters, except
assigning peers.
crypto dynamic-map vpndynamic 10
set transform-set ts
match address vpn
reverse-route
!Create crypto-map and snap to it already created dynamic crypto-map.
crypto map dynmap 10 ipsec-isakmp dynamic vpndynamic
!Assign crypto-map on external interface. In our case Fa0/0. After this
ISAKMP will turn on.
interface FastEthernet0/0
crypto map dynmap
Verification:
Now the configuration is done and let’s start checking if it works. First of all
ping SRV from host1. Check the following: Is VPN tunnel established or
not, decaps/encaps increases or not, RRI (reverse-route injection) is added
in Branche1 and HQ Routing Tables and also if hit counts in access lists
change or not.
MORE READING: Overview of Cisco ASA VPN Technologies and Types
!We see, that first few pings are lost, because VPN tunnel takes some time
to get established.
host1#ping [Link]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 40/96/164
ms
host1#ping [Link]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to [Link], timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/62/124
ms
!Now check if ISAKMP peers are in state or not.
hq#show crypto isakmp sa
dst src state conn-id slot status
[Link] [Link] QM_IDLE 1 0 ACTIVE
branch1#show crypto isakmp sa
dst src state conn-id slot
[Link] [Link] QM_IDLE 1 0
!Let’s see again if encaps/decaps increase. If not and they ping each other,
this means that traffic is not going through VPN tunnel.
branch1#show crypto ipsec sa
interface: FastEthernet0/0
crypto map tag: vpn, local addr. [Link]
protected vrf:
local ident (addr/mask/prot/port): ([Link]/[Link]/0/0)
remote ident (addr/mask/prot/port): ([Link]/[Link]/0/0)
current_peer: [Link]:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 13, #pkts encrypto: 13, #pkts digest 13
#pkts decaps: 12, #pkts decrypto: 12, #pkts verify 12
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
hq#show crypto ipsec sa
interface: FastEthernet0/0
crypto map tag: dynmap, local addr [Link]
protected vrf: (none)
local ident (addr/mask/prot/port): ([Link]/[Link]/0/0)
remote ident (addr/mask/prot/port): ([Link]/[Link]/0/0)
current_peer [Link] port 500
PERMIT, flags={}
#pkts encaps: 12, #pkts encrypto: 12, #pkts digest: 12
#pkts decaps: 13, #pkts decrypto: 13, #pkts verify: 13
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
!Let’s check that RRI is all right and access lists are matched.
hq#show ip route static
S [Link]/24 [1/0] via [Link]
branch1#show ip route static
S [Link]/24 [1/0] via [Link]
hq#show access-lists vpn
Extended IP access list vpn
10 permit ip [Link] [Link] [Link] [Link]
20 permit ip [Link] [Link] [Link] [Link] (25 matches)
branch1#show access-lists vpn
Extended IP access list vpn
10 permit ip [Link] [Link] [Link] [Link] (26 matches)
All the above indicate that everything is all right and VPN is working
properly. Also remember that we’ve not assigned peers in HQ configuration
and that makes configuration simple (when we have 20 branches there is
no need for assigning static peers of Branches on the HQ site). Another
great advantage of dynamic crypto map on the HQ site is when a branch
site receives dynamic public IP address from the ISP.