In this last article on the bridging VPNs topic, we will consider how our scenario can be achieved on Cisco ASAs. There is a good chance that you will be using your firewall appliances to terminate VPN connections so I believe this is very useful to know.

The scenario we have been looking at is as follows: Site A and Site B have a site-to-site VPN connection between themselves. Site C is a new site that also needs to have VPN access to Site B, but for some reason, this new VPN access has to go through Site A which will then route it to site B.

The diagram we will be using for this article is as follows:

The above diagram is just a logical one showing the networks to be protected by the VPN. In the physical topology, each ASA is connected to a router connected on its inside interface and those routers have loopback interfaces as shown below:

Note: For this lab, the Internet cloud is just a router (R4) with three interfaces using the IP addresses 192.168.10.2, 192.168.20.2 and 192.168.30.2.

The Cisco ASA does not support the concept of tunnels, so we are stuck with using crypto maps just like we did in the first article on this topic. You can refer to these articles on how to configure site-to-site VPN on the Cisco ASA: VPN on Cisco ASA part 1 and part 2.

The basic configuration on the ASAs, including IP addressing and routing, is as follows:

ASA1

interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 192.168.10.1 255.255.255.0
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 10.10.10.1 255.255.255.0
!
route inside 1.1.1.1 255.255.255.255 10.10.10.2
route outside 2.2.2.2 255.255.255.255 192.168.20.1
route outside 3.3.3.3 255.255.255.255 192.168.30.1
route outside 192.168.20.0 255.255.255.0 192.168.10.2
route outside 192.168.30.0 255.255.255.0 192.168.10.2

ASA2

interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 192.168.20.1 255.255.255.0
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 10.10.20.1 255.255.255.0
!
route outside 1.1.1.1 255.255.255.255 192.168.10.1
route inside 2.2.2.2 255.255.255.255 10.10.20.2
route outside 3.3.3.3 255.255.255.255 192.168.10.1
route outside 192.168.10.0 255.255.255.0 192.168.20.2

ASA3

interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 192.168.30.1 255.255.255.0
!
interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 10.10.30.1 255.255.255.0
!
route outside 1.1.1.1 255.255.255.255 192.168.10.1
route outside 2.2.2.2 255.255.255.255 192.168.10.1
route inside 3.3.3.3 255.255.255.255 10.10.30.2
route outside 192.168.10.0 255.255.255.0 192.168.30.2

The important things to point out are how the route statements are set up:

  1. ASA1 routes 2.2.2.2/32 to ASA2 and 3.3.3.3/32 to ASA3.
  2. ASA2 routes both 1.1.1.1/32 and 3.3.3.3/32 to ASA1.
  3. ASA3 routes both 1.1.1.1/32 and 2.2.2.2/32 to ASA1.

This is exactly what we did in that first article so that all traffic between Site B and Site C go through Site A. Thus, Site A acts as a hub while Site B and Site C are spokes.

The VPN configuration on the Cisco ASAs is as follows:

ASA1

access-list SITEA-TO-SITEB extended permit ip host 1.1.1.1 host 2.2.2.2
access-list SITEA-TO-SITEB extended permit ip host 3.3.3.3 host 2.2.2.2
access-list SITEA-TO-SITEC extended permit ip host 1.1.1.1 host 3.3.3.3
access-list SITEA-TO-SITEC extended permit ip host 2.2.2.2 host 3.3.3.3
!
crypto ikev1 policy 1
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
!
crypto ipsec ikev1 transform-set TRANS_SET esp-3des esp-md5-hmac
!
crypto map CRYP_MAP 10 match address SITEA-TO-SITEB
crypto map CRYP_MAP 10 set peer 192.168.20.1
crypto map CRYP_MAP 10 set ikev1 transform-set TRANS_SET

crypto map CRYP_MAP 20 match address SITEA-TO-SITEC
crypto map CRYP_MAP 20 set peer 192.168.30.1
crypto map CRYP_MAP 20 set ikev1 transform-set TRANS_SET
crypto map CRYP_MAP interface outside
crypto ikev1 enable outside
!
tunnel-group 192.168.20.1 type ipsec-l2l
tunnel-group 192.168.20.1 ipsec-attributes
ikev1 pre-shared-key cisco
tunnel-group 192.168.30.1 type ipsec-l2l
tunnel-group 192.168.30.1 ipsec-attributes
ikev1 pre-shared-key cisco

ASA2

access-list SITEB-TO-SITEA extended permit ip host 2.2.2.2 host 1.1.1.1
access-list SITEB-TO-SITEA extended permit ip host 2.2.2.2 host 3.3.3.3
!
crypto ikev1 policy 1
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
!
crypto ipsec ikev1 transform-set TRANS_SET esp-3des esp-md5-hmac
!
crypto map CRYP_MAP 10 match address SITEB-TO-SITEA
crypto map CRYP_MAP 10 set peer 192.168.10.1
crypto map CRYP_MAP 10 set ikev1 transform-set TRANS_SET
crypto map CRYP_MAP interface outside
crypto ikev1 enable outside
!
tunnel-group 192.168.10.1 type ipsec-l2l
tunnel-group 192.168.10.1 ipsec-attributes
 ikev1 pre-shared-key cisco

ASA3

access-list SITEC-TO-SITEA extended permit ip host 3.3.3.3 host 1.1.1.1
access-list SITEC-TO-SITEA extended permit ip host 3.3.3.3 host 2.2.2.2
!
crypto ikev1 policy 1
 authentication pre-share
 encryption 3des
 hash sha
 group 2
 lifetime 86400
!
crypto ipsec ikev1 transform-set TRANS_SET esp-3des esp-md5-hmac
!
crypto map CRYP_MAP 10 match address SITEC-TO-SITEA
crypto map CRYP_MAP 10 set peer 192.168.10.1
crypto map CRYP_MAP 10 set ikev1 transform-set TRANS_SET
crypto map CRYP_MAP interface outside
crypto ikev1 enable outside
!
tunnel-group 192.168.10.1 type ipsec-l2l
tunnel-group 192.168.10.1 ipsec-attributes
 ikev1 pre-shared-key cisco

Testing VPN tunnels

The first test I will conduct is if Site A can connect to both Sites B and C via their respective VPN tunnels. To do this, I will ping from R1 (1.1.1.1) to both R2 (2.2.2.2) and R3 (3.3.3.3).

As you can see, the ping was successful. We can verify that the packets were encrypted by looking at the IPsec SAs on ASA1:

We can see that the packets were encrypted and decrypted, meaning that they went across the tunnel.

Our second test involves connecting from Site B to Site C (or vice versa). I will go to R2 and attempt to ping R3.

To understand why this didn’t work, let’s first trace the traffic path. R2 sends the ping traffic to its default gateway which is ASA2.

ASA2 receives the traffic and, based on its routing table, it should forward it towards ASA1 (192.168.10.1) through its “outside” interface.

Also, ASA2 sees that the traffic matches traffic to be protected in a VPN tunnel so it sends it across the VPN to ASA1.

ASA1 receives that traffic and based on its routing table, it should forward the traffic to ASA3 through its “outside” interface.

Here is where the problem lies: ASA1 receives traffic on its outside interface and must also forward that same traffic back out the same interface to the traffic’s destination. This is known as Hairpinning or U-Turn traffic. A common example of U-turn traffic is when VPN clients connect to the company’s network and then use the Internet connection of the company also.

By default, U-turn traffic is not permitted on the Cisco ASA. To allow this type of traffic on ASA1, we need to enter the following command: same-security-traffic permit intra-interface. After entering this command, the connection will go through as shown below:

Summary

In this article, we have seen how to enable spoke-to-spoke communication over VPN tunnels configured on Cisco ASAs. The highlight of this article is that, for spokes to communicate, we need to allow traffic entering an interface to go out through the same interface. This is known as hairpinning and can be enabled using the same-security-traffic permit intra-interface command.

I hope you have found this article and the short series insightful.

Further reading