Cisco ASA 8.4 VPN — Dealing with Internet Hairpin Traffic

Over the past few months, I have received a few requests regarding hairpin scenarios and the ASA. Earlier, I provided a scenario that deals with hairpinning (also known as U-Turn) traffic between two VPN spokes in a typical ASA environment. In another article, I provided an example using an IOS based device to hairpin traffic between a VPN spoke and the Internet. This article simply provides a commented solution to the challenge of routing Internet bound traffic through an ASA based IPSec VPN. In this article, the firewall is running version 8.4 of the ASA operating system. To find the 8.2 equivalent example of this configuration, review the previous iteration of this article.

ASA Hairpin VPN to Internet

Based on the above diagram, our challenges are as follows:

  • Allow “InsideRTR” access to the Internet (192.0.2.254) using PAT
  • Require Encryption Between 192.168.1.0/24 and 10.2.2.0/24
  • Encrypt Traffic from VPNRTR to Internet Destinations (0.0.0.0/0) via the Firewall
  • Allow 10.2.2.0/24 to utilize the same PAT Process as “InsideRTR”

Router Configurations

InsideRTR

hostname InsideRTR
!
interface FastEthernet0/0
 ip address 192.168.1.5 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1

InetRTR

hostname InetRTR
!
//using dot1q to a switch (not shown)
interface FastEthernet0/0
 ip address 192.0.2.1 255.255.255.252
!
interface FastEthernet0/0.6
 ip address 192.0.2.6 255.255.255.252
!
interface FastEthernet0/0.10
 ip address 192.0.2.10 255.255.255.252
!
ip route 192.0.2.252 255.255.255.252 192.0.2.9

CustRTR

hostname CustRTR
!
interface Loopback0
 ip address 192.0.2.254 255.255.255.252
!
interface FastEthernet0/0
 ip address 192.0.2.9 255.255.255.252
!
ip route 0.0.0.0 0.0.0.0 192.0.2.10

VPNRTR–All Loopback Sourced Traffic Will Go through VPN

hostname VPNRTR
!
//begin IKE phase 1 configuration
crypto isakmp policy 10
 encr aes
 authentication pre-share
crypto isakmp key cisco address 192.0.2.2
!
//begin IKE phase 2 configuration
crypto ipsec transform-set MYSET esp-aes esp-sha-hmac 
!
//Crypto ACL (all loopback traffic through VPN)
ip access-list extended VPN
 permit ip 10.2.2.0 0.0.0.255 any
!
crypto map MYMAP 10 ipsec-isakmp 
 set peer 192.0.2.2
 set transform-set MYSET 
 match address VPN
!
interface Loopback0
 ip address 10.2.2.2 255.255.255.0
!
//physical interface with crypto policy attached
interface FastEthernet0/0
 ip address 192.0.2.5 255.255.255.252
 crypto map MYMAP
!
ip route 0.0.0.0 0.0.0.0 192.0.2.6

ASA VPN, PAT and Hairpin Configuration

//ASA5505 so it uses VLANs and Integrated Switch
hostname ASA
!
interface Ethernet0/0
 switchport access vlan 2
!
interface Ethernet0/1
!
...

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 192.0.2.2 255.255.255.252
...
route outside 0.0.0.0 0.0.0.0 192.0.2.1 1

//VPN Configuration (all traffic to 10.2.2.x)

access-list VPN extended permit ip any 10.2.2.0 255.255.255.0
!
tunnel-group 192.0.2.5 type ipsec-l2l
tunnel-group 192.0.2.5 ipsec-attributes
 ikev1 pre-shared-key cisco
!
crypto ipsec ikev1 transform-set MYSET esp-aes esp-sha-hmac 
crypto map MYMAP 10 match address VPN
crypto map MYMAP 10 set peer 192.0.2.5 
crypto map MYMAP 10 set ikev1 transform-set MYSET
crypto map MYMAP 10 set reverse-route
crypto map MYMAP interface outside
!
crypto isakmp identity address 
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption aes
 hash sha     
 group 1      
 lifetime 86400
!
//NAT Configuration

//exempt internal to 10.2.2.x from NAT, PAT other traffic

//object group creation
object network obj-192.168.1.0
 subnet 192.168.1.0 255.255.255.0
object network obj-10.2.2.0
 subnet 10.2.2.0 255.255.255.0
object network obj_any
 subnet 0.0.0.0 0.0.0.0

//nat exemption for the internal traffic going to 10.2.2.x
nat (inside,any) source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-10.2.2.0 obj-10.2.2.0 no-proxy-arp

//pat for the inside traffic
object network obj_any
 nat (inside,outside) dynamic interface

//pat for the VPN traffic
object network obj-10.2.2.0
 nat (outside,outside) dynamic interface

//allow traffic to hairpin on the interface
same-security-traffic permit intra-interface

Test VPN to Internet Hairpinning

VPNRTR

//enable "debug ip icmp" on CustRTR
//test with traffic that shouldn't be encrypted
VPNRTR#ping 192.0.2.254                  

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/40/52 ms

//test with traffic that should be hairpinned and use ASA PAT
VPNRTR#ping 192.0.2.254 source loopback 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.254, timeout is 2 seconds:
Packet sent with a source address of 10.2.2.2 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/40/44 ms

CustRTR Output

//debug already enabled prior to test
CustRTR#debug ip icmp 
ICMP packet debugging is on

//test traffic
//traffic that was direct (notice 192.0.2.5)
*Mar  1 01:28:19.987: ICMP: echo reply sent, src 192.0.2.254, dst 192.0.2.5
*Mar  1 01:28:20.031: ICMP: echo reply sent, src 192.0.2.254, dst 192.0.2.5
*Mar  1 01:28:20.071: ICMP: echo reply sent, src 192.0.2.254, dst 192.0.2.5
*Mar  1 01:28:20.115: ICMP: echo reply sent, src 192.0.2.254, dst 192.0.2.5
*Mar  1 01:28:20.155: ICMP: echo reply sent, src 192.0.2.254, dst 192.0.2.5

//traffic that was hairpinned (notice 192.0.2.2)
*Mar  1 01:28:34.479: ICMP: echo reply sent, src 192.0.2.254, dst 192.0.2.2
*Mar  1 01:28:34.503: ICMP: echo reply sent, src 192.0.2.254, dst 192.0.2.2
*Mar  1 01:28:34.543: ICMP: echo reply sent, src 192.0.2.254, dst 192.0.2.2
*Mar  1 01:28:34.591: ICMP: echo reply sent, src 192.0.2.254, dst 192.0.2.2
*Mar  1 01:28:34.635: ICMP: echo reply sent, src 192.0.2.254, dst 192.0.2.2

As I stated in the article about the 8.2 configuration of U-Turn NAT and VPN, I probably should make a couple of points to anyone who is looking into this. First, just because we can do this doesn’t mean we should. I very rarely find that making a configuration unnecessarily complex is beneficial. These, and other complex configurations, are really good exercises to understand how ASAs function and process traffic flows. For anyone that does find a beneficial use case for hairpinning, I recommend carefully labbing the initial configuration as well as future modifications.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To and tagged . Bookmark the permalink.

2 Responses to Cisco ASA 8.4 VPN — Dealing with Internet Hairpin Traffic

  1. CC says:

    im trying to pass traffic between two ASAs. One is running 8.2 and the other side is running 8.6

    I can get traffic to from the 8.6 asa (A) to 8.2 asa (B)
    I can NOT get traffic from (B) to (A)
    I can see the traffic leaving (A).

    It seems like I’m missing a NAT or access rule one the (A) side

    • I am assuming this is a Site to Site VPN configuration. To dig into this, it may be necessary to look through some of the configuration. I would suggest posting the following information from both ASAs over at the Cisco Learning Network. The url is below and the community is quite active-

      https://learningnetwork.cisco.com/threads

      Information needed
      Interface Addresses and Security Levels
      Whether or not sysopt permit-vpn is still enabled
      the output of “show run nat”
      Crypto Map and crypto acls
      Source and Destination IP addresses that aren’t able to reach each other

      There’s lot’s of possible configuration problems that could cause your issue.

Comments are closed.