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 192.168.4.0/24 and 192.168.5.0/24 must have secure access to subnet 192.168.1.0/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
! 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 192.168.2.2
! 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 192.168.4.0/24 and destination is 192.168.1.0/24 then traffic will be encrypted. Similarly for Branch 2, if source is 192.168.5.0/24 and destination is 192.168.1.0/24 then traffic will be encrypted.
Branch 1 ACL:
ip access-list extended vpn
permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255
Branch 2 ACL:
ip access-list extended vpn
permit ip 192.168.5.0 0.0.0.255 192.168.1.0 0.0.0.255
! 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 192.168.1.0/24.
crypto map vpn 10 ipsec-isakmp
set peer 192.168.2.2
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 0.0.0.0 0.0.0.0
! 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 192.168.1.0/24 and destination will be 192.168.4.0/24 and 192.168.5.0/24.
ip access-list extended vpn
permit ip 192.168.1.0 0.0.0.255 192.168.5.0 0.0.0.255
permit ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255
! 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.
!We see, that first few pings are lost, because VPN tunnel takes some time to get established.
host1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 40/96/164 ms
host1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, 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
192.168.2.2 192.168.3.2 QM_IDLE 1 0 ACTIVE
branch1#show crypto isakmp sa
dst src state conn-id slot
192.168.2.2 192.168.3.2 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. 192.168.3.2
protected vrf:
local ident (addr/mask/prot/port): (192.168.4.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
current_peer: 192.168.2.2: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 192.168.2.2
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.4.0/255.255.255.0/0/0)
current_peer 192.168.3.2 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 192.168.4.0/24 [1/0] via 192.168.3.2
branch1#show ip route static
S 192.168.1.0/24 [1/0] via 192.168.2.2
hq#show access-lists vpn
Extended IP access list vpn
10 permit ip 192.168.1.0 0.0.0.255 192.168.5.0 0.0.0.255
20 permit ip 192.168.1.0 0.0.0.255 192.168.4.0 0.0.0.255 (25 matches)
branch1#show access-lists vpn
Extended IP access list vpn
10 permit ip 192.168.4.0 0.0.0.255 192.168.1.0 0.0.0.255 (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.