It seems like some of the more challenging things to do on an ASA involve some sort of traffic being redirected out the same interface it was received on. This article addresses the requirement for spoke to hub to spoke communication for LAN to LAN VPNs.  This is less efficient and should not be used when there are massive amounts of traffic between to spokes.  However if your design requires fewer peers, a more compact configuration and you prefer a simple solution, this article can help you achieve those goals. Although this article specifically addresses the LAN to LAN VPN type, the methods used here can work with other types of VPNs as well (e.g. Anyconnect and IPSec Remote Access).

Before we get deep into the configuration, I wanted to go over the diagram of my network and explain the initial configuration.

The initial configuration allows the 10.3.3.0/24 addresses at "Spoke A" to communicate with the 192.168.1.0/24 addresses at our hub site (Inside). Likewise 192.168.1.0/24 addresses at "Inside" can communicate with 10.3.3.0/24 at "Spoke A". Similar communication is permitted between the hub site and "Spoke B". This is done via LAN to LAN IPSec Tunnel.  There is nothing in place to allow the RFC1918 addresses at the spoke sites to communicate with one another.

Skip Initial Configuration

ISP (configuration will not change)

hostname ISP ! ! interface FastEthernet0/0  ip address 1.1.1.6 255.255.255.0  speed auto ! interface Serial0/0.603 point-to-point  ip address 1.3.3.6 255.255.255.0  frame-relay interface-dlci 603 ! interface Serial0/0.607 point-to-point  ip address 1.7.7.6 255.255.255.0  frame-relay interface-dlci 607 !

Inside (configuration will not change)

 hostname Inside ! ! interface FastEthernet0/0  ip address 192.168.1.5 255.255.255.0  speed auto ! ip route 0.0.0.0 0.0.0.0 192.168.1.1 ! 

ASA (HUB)

 hostname ASA ! interface Vlan1  nameif inside  security-level 100  ip address 192.168.1.1 255.255.255.0 ! interface Vlan2  nameif outside  security-level 0  ip address 1.1.1.2 255.255.255.0 ! ! access-list VPN3 extended permit ip 192.168.1.0 255.255.255.0 10.3.3.0 255.255.255.0 ! access-list VPN7 extended permit ip 192.168.1.0 255.255.255.0 10.7.7.0 255.255.255.0 ! access-list NONAT extended permit ip 192.168.1.0 255.255.255.0 10.3.3.0 255.255.255.0 access-list NONAT extended permit ip 192.168.1.0 255.255.255.0 10.7.7.0 255.255.255.0 ! global (outside) 1 interface  nat (inside) 0 access-list NONAT  nat (inside) 1 0.0.0.0 0.0.0.0 ! route outside 0.0.0.0 0.0.0.0 1.1.1.6 1 ! crypto ipsec transform-set MYSET esp-aes esp-sha-hmac crypto ipsec security-association lifetime seconds 28800 crypto ipsec security-association lifetime kilobytes 4608000 crypto map MYMAP 10 match address VPN3 crypto map MYMAP 10 set peer 1.3.3.3 crypto map MYMAP 10 set transform-set MYSET crypto map MYMAP 20 match address VPN7 crypto map MYMAP 20 set peer 1.7.7.7 crypto map MYMAP 20 set transform-set MYSET crypto map MYMAP interface outside crypto isakmp enable outside ! crypto isakmp policy 10  authentication pre-share  encryption aes  hash sha  group 2  lifetime 86400 ! tunnel-group 1.7.7.7 type ipsec-l2l tunnel-group 1.7.7.7 ipsec-attributes  pre-shared-key cisco ! tunnel-group 1.3.3.3 type ipsec-l2l tunnel-group 1.3.3.3 ipsec-attributes  pre-shared-key cisco 

Spoke A

 hostname SpokeA ! ! //because my RTR can't do AES in HW no crypto engine accelerator ! ! crypto isakmp policy 10  encr aes  authentication pre-share  group 2 crypto isakmp key cisco address 1.1.1.2 ! ! crypto ipsec transform-set MYSET esp-aes esp-sha-hmac ! crypto map MYMAP 10 ipsec-isakmp  set peer 1.1.1.2  set transform-set MYSET  match address 101 ! interface Loopback0  ip address 10.3.3.3 255.255.255.0 ! ! interface Serial0/0.306 point-to-point  ip address 1.3.3.3 255.255.255.0  frame-relay interface-dlci 306  crypto map MYMAP ! ip route 0.0.0.0 0.0.0.0 1.3.3.6 ! ! access-list 101 permit ip 10.3.3.0 0.0.0.255 192.168.1.0 0.0.0.255 ! line vty 0 4  password cisco  login  transport input all line vty 5 15  password cisco  login  transport input all ! end

Spoke B

 hostname SpokeB ! ! //because my RTR can't do AES in HW no crypto engine accelerator ! ! crypto isakmp policy 10  encr aes  authentication pre-share  group 2 crypto isakmp key cisco address 1.1.1.2 ! ! crypto ipsec transform-set MYSET esp-aes esp-sha-hmac ! crypto map MYMAP 10 ipsec-isakmp  set peer 1.1.1.2  set transform-set MYSET  match address 101 ! interface Loopback0  ip address 10.7.7.7 255.255.255.0 ! ! interface Serial0/0.306 point-to-point  ip address 1.7.7.7 255.255.255.0  frame-relay interface-dlci 306  crypto map MYMAP ! ip route 0.0.0.0 0.0.0.0 1.7.7.6 ! ! access-list 101 permit ip 10.7.7.0 0.0.0.255 192.168.1.0 0.0.0.255 ! line vty 0 4  password cisco  login  transport input all line vty 5 15  password cisco  login transport input all ! end

Spoke to Hub to Spoke

In our initial configuration, we have spoke to hub and hub to spoke communication. There is no spoke to spoke communication.  In order to achieve spoke to spoke communication, we need to first instruct the spokes encrypt and tunnel the traffic that is destined to the remote spoke. In this case, we are going to build the tunnel to the hub site.

Spoke A (additional commands)

 //crypto acl--traffic to encrypt access-list 102 permit ip 10.3.3.0 0.0.0.255 10.7.7.0 0.0.0.255 ! //crypto map entry--peer, encryption //properties and interesting traffic crypto map MYMAP 20 ipsec-isakmp  set peer 1.1.1.2  set transform-set MYSET  match address 102 

Spoke B (additional commands)

 //crypto acl--traffic to encrypt access-list 102 permit ip 10.7.7.0 0.0.0.255 10.3.3.0 0.0.0.255 ! //crypto map entry--peer, encryption //properties and interesting traffic crypto map MYMAP 20 ipsec-isakmp  set peer 1.1.1.2  set transform-set MYSET  match address 102 

The next step is to mirror the spoke configuration in our ASA at the hub site.

ASA (additional commands)

 //instruct ASA that it can send traffic //back out the receive interface same-security-traffic permit intra-interface  //addition to crypto acl toward Spoke A access-list VPN3 extended permit ip 10.7.7.0 255.255.255.0 10.3.3.0 255.255.255.0  //addition to crypto acl toward Spoke B access-list VPN7 extended permit ip 10.3.3.0 255.255.255.0 10.7.7.0 255.255.255.0

Verification

Now we need to verify the functionality. The goal is to achieve spoke to spoke functionality between the private addresses. This traffic should use the tunnels between the hub and spokes.

 SpokeA#ping 10.7.7.7 source 10.3.3.3  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.7.7.7, timeout is 2 seconds: Packet sent with a source address of 10.3.3.3  *Jul 1 03:24:57.150: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP . Peer 1.1.1.2:500 Id: 1.1.1.2..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 12/13/16 ms 

Since the tunnel had to establish, we lost the first couple of pings. One more test should be 100%.

 SpokeA#ping 10.7.7.7 source 10.3.3.3  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.7.7.7, timeout is 2 seconds: Packet sent with a source address of 10.3.3.3 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/13/16 ms

Let's make sure that something more sophisticated than ping works.

 SpokeA#telnet 10.7.7.7 /source-interface l0 Trying 10.7.7.7 ... Open  User Access Verification  Password: SpokeB> SpokeB>exit  [Connection to 10.7.7.7 closed by foreign host] 

It seems to be working, but is it going through the tunnel to the hub? Let's look at the IPSec SA's.

 SpokeA#show crypto ipsec sa | inc addr|caps Crypto map tag: MYMAP, local addr. 1.3.3.3 local ident (addr/mask/prot/port): (10.3.3.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.7.7.0/255.255.255.0/0/0) #pkts encaps: 85, #pkts encrypt: 85, #pkts digest: 85 #pkts decaps: 70, #pkts decrypt: 70, #pkts verify: 70 local ident (addr/mask/prot/port): (10.3.3.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0) #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4 SpokeA#

We have now seen the configuration specifics of an ASA 8.2 for connecting two VPN Spokes through a single ASA Hub.  Many organizations are migrating their ASAs to version 8.4.  As we know, much of the configuration syntax is radically different in the new version. Fortunately, none of the specifics for the spoke to spoke communications actually requires a change. The only difference with the above configuration and the configuration in 8.4 are the changes in the NAT syntax. Although these changes affect the Inside to Spoke communication, they are irrelevant to the Spoke to Spoke communication.

Changes to the ASA config in 8.4

 //nat config in 8.2 ! access-list NONAT extended permit ip 192.168.1.0 255.255.255.0 10.3.3.0 255.255.255.0 access-list NONAT extended permit ip 192.168.1.0 255.255.255.0 10.7.7.0 255.255.255.0 ! global (outside) 1 interface nat (inside) 0 access-list NONAT nat (inside) 1 0.0.0.0 0.0.0.0 ! //the new and more complex nat configuration //after migrating to 8.4 ASA# show run object object network obj-192.168.1.0 subnet 192.168.1.0 255.255.255.0 object network obj-10.3.3.0 subnet 10.3.3.0 255.255.255.0 object network obj-10.7.7.0 subnet 10.7.7.0 255.255.255.0 object network obj_any subnet 0.0.0.0 0.0.0.0 ASA# show run nat nat (inside,any) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-10.3.3.0 obj-10.3.3.0 no-proxy-arp nat (inside,any) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-10.7.7.0 obj-10.7.7.0 no-proxy-arp ! object network obj_any nat (inside,outside) dynamic interface

Sending spoke to spoke traffic through a hub site is less than optimal. However, there are cases in which it may make sense. If an organization has more than a few sites, building a full mesh of static LAN to LAN VPN's may be and administrative nightmare. If there is only a need to deliver small amounts of spoke to spoke traffic, this solution may be an alternative. Additionally, there are solutions that are outside the capabilities of the ASA that may be better suited to this environment. Examples of IOS based solutions that might scale better are GETVPN (Group Encrypted Transport VPN) and DMVPN (Dynamic Multipoint VPN).