Networks Training

  • About
  • My Books
  • SUGGESTED TRAINING
  • HOME
  • Cisco Networking
    • Cisco General
    • Cisco IOS
    • Cisco VPN
    • Cisco Wireless
  • Cisco ASA
    • Cisco ASA General
    • Cisco ASA Firewall Configuration
  • Certifications Training
    • CCNA Training
    • Cisco Certifications
    • I.T Training
  • General
    • General Networking
    • IP Telephony
    • Network Security
    • Product Reviews
    • Software
  • Cisco Routers
  • Cisco Switches
You are here: Home / Cisco VPN / Site to Site VPN with Dynamic Crypto Map

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 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

MORE READING:  Cisco VPN Client Setup and Configuration

! 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.

MORE READING:  Site-to-Site IPSEC VPN Between Cisco ASA and pfSense

!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.

Related Posts

  • VPN Failover with HSRP High Availability (Crypto Map Redundancy)
  • Cisco IPsec Tunnel vs Transport Mode with Example Config
  • Cisco DMVPN Configuration Example
  • Site to Site IPSEC VPN Between Cisco Router and Juniper Security Gateway
  • Site-to-Site IPSEC VPN Between Cisco ASA and pfSense

Filed Under: Cisco VPN

Download Free Cisco Commands Cheat Sheets

Enter your Email below to Download our Free Cisco Commands Cheat Sheets for Routers, Switches and ASA Firewalls.

We use Elastic Email as our marketing automation service. By submitting this form, you agree that the information you provide will be transferred to Elastic Email for processing in accordance with their Terms of Use and Privacy Policy. Also, you allow me to send you informational and marketing emails from time-to-time.

About Harris Andrea

Harris Andrea is an Engineer with more than two decades of professional experience in the fields of TCP/IP Networks, Information Security and I.T. Over the years he has acquired several professional certifications such as CCNA, CCNP, CEH, ECSA etc.

He is a self-published author of two books ("Cisco ASA Firewall Fundamentals" and "Cisco VPN Configuration Guide") which are available at Amazon and on this website as well.

Comments

  1. Jose Manuel says

    April 20, 2011 at 5:42 pm

    But in this case you did not have applied NAT policies. I still have to exempt the interested traffic from the NAT process at the HQ router in order to reach the remote offices ¿right?

    Regards

  2. Blog Admin says

    April 21, 2011 at 8:42 pm

    Jose,

    Yes you are right. The article here is just an example in a Lab. In real world scenario where you have private IP addresses on the LAN and you want to do NAT for accessing the internet, then you must configure NAT exemption on the traffic that goes through the VPN tunnel.

  3. ITatSea says

    August 23, 2011 at 3:05 pm

    Thanks for the guide, this really helped.
    Especially the “revere-route” command could get it our VPN working without it!

    Thanks again

  4. Robert Thornton says

    February 10, 2012 at 8:04 pm

    I have an SR520 that has site to site tunnels set up where both ends have static WAN IP addresses. I would like to set up a few tunnels that connect to sites with dynamic WAN IP’s. I need to create the dynamic crypto map and apply it to the Outside interface but I already have the static crypto map and I don’t think you can have more than one crypto assigned to the Outside interface. Can you explain how to get around this? Thank you

  5. Blog Admin says

    February 15, 2012 at 3:39 pm

    Robert,

    You can have the same crypto map name (assigned to the outside interface) and then create numerous entries in the same crypto map (numbered 10,20,30 etc) and each entry can be a static or dynamic crypto

  6. Robert Thornton says

    February 15, 2012 at 6:50 pm

    I am gaining on it now but still not quite there. Thank you for the assistance.

  7. Shamir says

    October 18, 2012 at 2:17 pm

    This is incorrect…..If we add more spokes, configuration will be done only on spoke site and there is no need for changing anything on HUB.

    Yes, you need to add “ip access-list extended vpn” entries on Hub Site for new Spoke Site’s LAN as well NAT0 (exempt) rules….!

  8. Shamir says

    October 18, 2012 at 2:18 pm

    If we add more spokes, configuration will be done only on spoke site and there is need for changing on HUB site as well.

    Yes, you need to add “ip access-list extended vpn” entries on Hub Site for new Spoke Site’s LAN as well NAT0 (exempt) rules….!

  9. Blog Admin says

    October 18, 2012 at 4:27 pm

    Shamir,

    My statement that you don’t change anything on Hub site I mean you don’t add extra crypto map entries. You are right that you still need to add extra ACL lines in the vpn access list. Also, if you have NAT (which is not used in the lab scenario above) then you also need to add extra lines in the NAT exemption ACL

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search this site

About Networks Training

We Provide Technical Tutorials and Configuration Examples about TCP/IP Networks with focus on Cisco Products and Technologies. This blog entails my own thoughts and ideas, which may not represent the thoughts of Cisco Systems Inc. This blog is NOT affiliated or endorsed by Cisco Systems Inc. All product names, logos and artwork are copyrights/trademarks of their respective owners.

Amazon Disclosure

As an Amazon Associate I earn from qualifying purchases.
Amazon and the Amazon logo are trademarks of Amazon.com, Inc. or its affiliates.

Search

BLOGROLL

Tech21Century
Firewall.cx

Copyright © 2023 | Privacy Policy | Terms and Conditions | Hire Me | Contact | Amazon Disclaimer | Delivery Policy

1 shares