Usually when we configure site-to-site VPN tunnels, we know both peers at the end of the tunnel beforehand. In such cases, we can statically define the VPN peer on either peer in the site-to-site VPN configuration. However, there are cases where one of the peers that will be terminating the VPN tunnel is not known ahead of time, i.e., they are dynamic. This is common for remote-access VPN tunnels where VPN clients connect to a VPN gateway but it is also possible for site-to-site VPN tunnels which we will consider in this article.

Imagine a case where a router gets its address via DHCP. If that router is to be part of a site-to-site VPN tunnel, then the peer at the other end cannot preconfigure the IP address of this router in its VPN configuration, since that address is dynamically assigned. Therefore, on that other peer we need to have some sort of “wild card” crypto map to match any IP address from which the router will be coming from. Of course the dynamically addressed router itself will have a static peer configuration for the other peer.

Let’s use the diagram below to illustrate this concept:

We want to create a VPN tunnel between SITEA-RTR and SITEB-ASA to protect traffic between the 192.168.10.0/24 and 192.168.20.0/24 subnets. SITEB-ASA has a static IP address, but the public IP address of the SITEA-RTR is dynamically assigned. Therefore, the configuration on the SITEA-RTR side will be the normal VPN configuration we are familiar with, but we have to use a dynamic crypto map on the SITEB-ASA.

The ‘INTERNET’ cloud is a router with the following configuration (also acting as a DHCP server):

hostname INTERNET

!

interface FastEthernet0/0

ip address 203.0.113.1 255.255.255.0

!

interface FastEthernet0/1

ip address 41.1.1.1 255.255.255.252

!

ip dhcp pool PUBLIC-IPs

network 203.0.113.0 255.255.255.0

default-router 203.0.113.1

The configuration on the SITEA-RTR is shown below. As you can see, it is a normal site-to-site VPN configuration:

hostname SITEA-RTR

!

ip access-list extended VPNACL

permit ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255

!

crypto isakmp policy 10

encr 3des

authentication pre-share

hash sha

group 2

!

crypto isakmp key cisco address 41.1.1.2

!

crypto ipsec transform-set MYSET esp-3des esp-md5-hmac

!

crypto map CRYPMAP 10 ipsec-isakmp

set peer 41.1.1.2

set transform-set MYSET

match address VPNACL

!

interface Loopback0

ip address 192.168.10.10 255.255.255.0

!

interface FastEthernet0/0

ip address dhcp

crypto map CRYPMAP

!

ip route 192.168.20.0 255.255.255.0 FastEthernet0/0 41.1.1.2

We can confirm that the router has received an IP address from the DHCP server:

The configuration on the ASA is where things get interesting. We need to configure a dynamic crypto map so that it can receive VPN termination requests from any IP address. The only element required in a dynamic crypto map is the transform set. We then need to attach this dynamic crypto map to a normal crypto map. The dynamic crypto map should have the highest sequence number (lowest priority) in the crypto map so that it is evaluated last. Finally, we need to configure the pre-shared key under the default L2L tunnel-group (“DefaultL2LGroup”). You can view the default tunnel groups on the ASA using the show run all tunnel-group command.

The configuration on the SITEB-ASA is as follows:

hostname SITEB-ASA

!

interface GigabitEthernet0

nameif outside

security-level 0

ip address 41.1.1.2 255.255.255.252

!

interface GigabitEthernet1

nameif inside

security-level 100

ip address 192.168.20.1 255.255.255.0

!

route outside 0.0.0.0 0.0.0.0 41.1.1.1

!

crypto ikev1 policy 10

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

!

crypto ikev1 enable outside

!

crypto ipsec ikev1 transform-set MYSET esp-3des esp-md5-hmac

!

crypto dynamic-map DYNMAP 1 set ikev1 transform-set MYSET

crypto map CRYPMAP 65535 ipsec-isakmp dynamic DYNMAP

crypto map CRYPMAP interface outside

!

tunnel-group DefaultL2LGroup ipsec-attributes

ikev1 pre-shared-key cisco

The configuration on the SITEB-LAN-RTR is as follows:

hostname SITEB-LAN-RTR

!

interface FastEthernet0/0

ip address 192.168.20.20 255.255.255.0

!

ip route 0.0.0.0 0.0.0.0 192.168.20.1

Now let’s test our VPN configuration. Since the ASA has a dynamic crypto map, it cannot be the one to initiate the VPN tunnel. We need to initiate it from the router.

As you can see, even though I didn’t configure any VPN ACL on the ASA’s crypto map, the ASA learned this dynamically from the initiating peer.

Reverse Route Injection

In my configuration above, I have set the default gateway on the SITEB-LAN-RTR as the ASA. This is the reason the ping was successful. However, there may be cases where you want the ASA to advertise the dynamically learned addresses to other devices on the network. We can use reverse route injection (RRI) to achieve this. With RRI, the ASA installs a static route for the dynamically learned address in its routing table and we can then redistribute this static route by using a dynamic routing protocol.

On the ASA, we will enable RRI on the dynamic crypto map and also run EIGRP on its inside subnet:

crypto dynamic-map DYNMAP 1 set reverse-route

!

router eigrp 10

no auto-summary

network 192.168.20.0 255.255.255.0

redistribute static

On the SITEB-LAN-RTR, we will enable EIGRP as a routing protocol and remove the default route:

router eigrp 10

network 192.168.20.0

no auto-summary

!

no ip route 0.0.0.0 0.0.0.0 192.168.20.1

I will clear the crypto SAs between the ASA and the router and you will notice that the only static route in the ASA’s routing table is the default route via the INTERNET router:

Now when I initiate the VPN tunnel again, the static route for 192.168.10.0/24 is installed in the ASA’s routing table:

Also, the static route is advertised via EIGRP to the SITEB-LAN-RTR:

Using “any” in the Crypto Map ACL

One thing I found out is that if you use “any” in the ACL applied under the crypto map (on the dynamic peer. i.e.. SITEA-RTR), the VPN tunnel will not come up. For example, if the following access list is applied under the crypto map at the dynamic peer, the tunnel will not form:

ip access-list extended VPNACL

permit tcp any any

The logs on the ASA will reveal something like:

I’m not really sure why this happens because this same ACL will work for a static site-to-site VPN tunnel. I just thought to mention this because it cost me a lot of troubleshooting time and it may help someone.

Summary

In this article, we have configured a site-to-site VPN tunnel between a router with a dynamically allocated IP address and a Cisco ASA with a static IP address. The configuration on the router is normal VPN configuration, but we used a dynamic crypto map on the Cisco ASA.

We also discussed how the access list used under the crypto map at the dynamic peer cannot contain the “any” keyword; otherwise, the tunnel will not come up. If anyone knows the reason behind this, please drop a comment.

I hope you have found this article insightful.

References

  1. Using Dynamic Crypto Maps: http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/vpn_ike.html#wp1042880
  2. Dynamic IPsec Tunnel Between a Statically Addressed ASA and a Dynamically Addressed Cisco IOS Router that uses CCP Configuration Example: http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/112075-dynamic-ipsec-asa-router-ccp.html