Dynamic Site-2-Site VPNs with Cisco ASA

So let’s take a moment and assume your life is too easy, and you want to punish yourself. But how?! Here’s a way, let’s use the ASA for sites-2-site VPN. Even better, the spoke sites have be able to have dynamic IPs, and also need connectivity to other spokes. Also, IKEv2. Just because. Everyone ready?! I know I am.

Honestly, it’s actually incredibly easy. If you’re not familiar with the ASA’s ability to form dynamic L2L tunnels this post might be an eye opener. The tricky part is getting spoke to spoke connectivity in a reasonable fashion. However, we’ll cross that bridge when we come to it. Let’s look at the amazingly complex and overwhelming topology we’ll be working with today.

crypto ipsec ikev2 ipsec-proposal AES256
 protocol esp encryption aes-256
 protocol esp integrity sha-512
!
crypto ipsec security-association lifetime seconds 3600
!
crypto dynamic-map DYNAMIC-S2S 1 set pfs 
crypto dynamic-map DYNAMIC-S2S 1 set ikev2 ipsec-proposal AES256
crypto dynamic-map DYNAMIC-S2S 1 set reverse-route
crypto map VPNMAP 65535 ipsec-isakmp dynamic DYNAMIC-S2S
crypto map VPNMAP interface OUTSIDE
!
tunnel-group DefaultL2LGroup ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco123
 ikev2 local-authentication pre-shared-key cisco123

That’s about it for the crypto. The tunnel-group name has to be DefaultL2LGroup. One thing of particular note that I do not care for, with this model any dynamic tunnel peers have to share the same PSK. You’ll also take notice I didn’t specify any interesting traffic, nor did I set any peers. I also really like using reverse-route to inject static routes into the RIB, if you’re going to do that on the Hub just keep in mind you have to do this under the dynamic map.

Now on the Hub, let’s setup our nat exempt which will look a little different than it does on spoke ASAs.

object-group network ALLSITES
 network-object 192.168.1.0 255.255.255.0
 network-object 192.168.2.0 255.255.255.0
 network-object 192.168.3.0 255.255.255.0
!
nat (any,OUTSIDE) source static ALLSITES ALLSITES destination static ALLSITES ALLSITES
!

So pretty basic, we’re just using a single object-group with our subnets included. Then in the actual NAT configuration we’re saying the internal nameif is “any”. This is because as traffic transits the hub from spoke-2-spoke, we want this policy to pick that up along with traffic from the Hub’s inside to Spokes. Alternatively, you could have separate NAT statements. One for (INSIDE,OUTSIDE) and another for (OUTSIDE,OUTSIDE). The later of which being for spoke-2-spoke communication. Alright! Moving along, the config on the spokes looks a little something like this.

crypto ipsec ikev2 ipsec-proposal AES256
 protocol esp encryption aes-256
 protocol esp integrity sha-512
!
crypto ipsec security-association lifetime seconds 3600
!
object-group network LAN

 network-object 192.168.2.0 255.255.255.0
!
access-list L2LVPN extended permit ip object-group LAN 192.168.0.0 255.255.0.0 
!
crypto map VPNMAP 1 match address L2LVPN
crypto map VPNMAP 1 set pfs 
crypto map VPNMAP 1 set peer 200.1.1.1 
crypto map VPNMAP 1 set ikev2 ipsec-proposal AES256

crypto map VPNMAP interface OUTSIDE
!
tunnel-group 200.1.1.1 type ipsec-l2l
tunnel-group 200.1.1.1 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco123

 ikev2 local-authentication pre-shared-key cisco123
!
nat (INSIDE,OUTSIDE) source static ALLSITES ALLSITES destination static ALLSITES ALLSITES
!


That’s right, stock standard L2L VPN tunnel back to the hub. The above config is applied to ASAv2, however the only change in the configuration on ASAv3 is in “object-group network LAN”, instead of 192.168.2.0, ASAv3 has 192.168.3.0. For our interesting traffic we’re saying anything from our local subnet going to 192.168.0.0/16. This is pretty important, in order to have consistent and mostly reliable communication between spokes, we need the SA formed with the hub to also cover traffic to other spokes. I demonstrated why in my video below. The quick and dirty answer is, the Hub doesn’t build tunnels outbound. Just by design, it’s responder only within the DefaultL2LGroup tunnel. So while ASAv2 will build it’s SA for S2>>S3 to the Hub, the Hub can’t actually build the second half of that connection. Leaving you seeing a single SA for 192.168.2.0>>192.168.3.0 with the peer being ASAv2. The hub can receive that traffic, but will be unable to build the new SA out to S3 to actually forward it along. Again though, this is a non-issue if your Spokes are building tunnels where the destination covers all remote spoke subnets.

Well I could ramble on a bit longer, but that’s the jist of it boys and girls. Linking the video below.