IPSec Hairpinning

Well, no I am not love with hairpinning, but come to think of it, this can be a useful feature.

For example, your remote sites are site-site VPNs to your HQ and you are at home, using remote access VPN to access the HQ. It would be nice, if you could access the remote sites as well, wouldn’t it ?

Our scenario or rather mission is such.

IPSEC Hairpinning Topology

We want to create a L2L VPN between ASA and R2 to encrypt traffic between 10.0.0.0/24 and 136.1.121.0/24 network.

Then we want users to access from R4, our ASA using EZVPN and these users should be allowed to send encrypted traffic over the already created L2L VPN. Static routes are permitted for this configuration.

All devices are running RIP ver 2 and have full reach-ability to each other.

NAT-Control is not enable on ASA.

Also, the topology  is similar to INE Remote access VPN labs, except, I have put R4 in VLAN 100 instead of a test PC.

We start with configuring a basic L2L VPN between ASA and R2.

Configuration:

ASA:

crypto isakmp policy 10

authen pre-share

group 2

hash md5

encryption 3des

!

crypto isakmp key CISCO address 136.1.23.2

!

crypto ipsec transform T_SET esp-3des esp-md5-hmac

!

access-list 122 permit ip 136.1.121.0 255.255.255.0 10.0.0.0 255.255.255.0

!

crypto map IMAP 5 set transform-set T_SET

crypto map IMAP 5 match address 122

crypto map IMAP 5 set peer 136.1.23.2

!

crypto map IMAP interface outside

R2:

crypto isakmp policy 10

authen pre-share

group 2

hash md5

encryption 3des

!

crypto isakmp key 0 CISCO address 136.1.123.12

!

crypto ipsec transform T_SET esp-3des esp-md5-hmac

!

access-list 122 permit ip 10.0.0.0 0.0.0.255 136.1.121.0 0.0.0.255

!

crypto map IMAP 5 isakmp-ipsec

set transform-set T_SET

match address 122

set peer 136.1.123.12

!

int S0/1

crypto map IMAP

!

Now to create an EZVPN tunnel, I would use the existing transform sets and crypto maps.

Here is the configuration on ASA , which is our EZVPN server

ASA:

ip local pool LOCAL_POOL 20.0.0.1-20.0.0.255

!

vpn-addr-assign local

!

group-policy EZVPN_POLICY internal

group-policy EZVPN_POLICY attributes

vpn-tunnel-protocol ipsec

address-pools value LOCAL_POOL

!

tunnel-group EZVPN type remote-access

tunnel-group EZVPN ipsec-attributes

pre-shared-key CISCO

tunnel-group EZVPN general-attributes

default-group-policy EZVPN_POLICY

authentication-server-group LOCAL

!

crypto dynamic-map D_MAP 100 set transform-set T_SET

crypto dynamic-map D_MAP 100 set reverse-route

crypto map IMAP 20 ipsec-isakmp dynamic D_MAP

!

router rip

redistribute static

!

R4 EZVPN remote (Client):

crypto ipsec client ezvpn EZVPN

group EZVPN key CISCO

connect auto

mode client

peer 136.1.123.12

int lo0

crypto ipsec client ezvpn EZVPN inside

!

int fa0/0

crypto ipsec client ezvpn EZVPN outside

!

We test both tunnels

For L2L:

R2:

ping 136.1.121.1 source fa0/0

Sending 5, 100-byte ICMP Echos to 136.1.121.1, timeout is 2 seconds:

Packet sent with a source address of 10.0.0.2

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 48/48/48 ms

Rack1ASA1#

sh crypto ipsec sa

interface: outside

Crypto map tag: IMAP, seq num: 5, local addr: 136.1.123.12

access-list 122 permit ip 136.1.121.0 255.255.255.0 10.0.0.0 255.255.255.0

local ident (addr/mask/prot/port): (136.1.121.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/0/0)

current_peer: 136.1.23.2

#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

please pay close attention to IPSEC SAs to understand the difference.

Now we bring up EZVPN tunnel and test it

Rack1R4#

crypto ipsec client ezvpn xauth

Username: test

Password:

Rack1R4#

Nov  6 09:33:29.201: %CRYPTO-6-EZVPN_CONNECTION_UP: (Client)  User=  Group=EZVPN  Client_public_addr=136.1.100.4  Server_public_addr=136.1.123.12  Assigned_client_addr=20.0.0.1

Rack1R4#

Nov  6 09:33:31.084: %LINK-3-UPDOWN: Interface Loopback10000, changed state to up

Nov  6 09:33:32.086: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10000, changed state to up

Rack1R4#

Rack1R1#

sh ip route

Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP

D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area

N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2

E1 – OSPF external type 1, E2 – OSPF external type 2

i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2

ia – IS-IS inter area, * – candidate default, U – per-user static route

o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

136.1.0.0/24 is subnetted, 5 subnets

C       136.1.11.0 is directly connected, FastEthernet0/0.11

R       136.1.23.0 [120/2] via 136.1.121.12, 00:00:22, FastEthernet0/0.121

R       136.1.100.0 [120/2] via 136.1.121.12, 00:00:22, FastEthernet0/0.121

C       136.1.121.0 is directly connected, FastEthernet0/0.121

R       136.1.123.0 [120/1] via 136.1.121.12, 00:00:22, FastEthernet0/0.121

20.0.0.0/32 is subnetted, 1 subnets

R       20.0.0.1 [120/1] via 136.1.121.12, 00:00:16, FastEthernet0/0.121

10.0.0.0/24 is subnetted, 1 subnets

R       10.0.0.0 [120/3] via 136.1.121.12, 00:00:23, FastEthernet0/0.121

Rack1R4#ping 150.1.1.1 source lo0 rep 10

Type escape sequence to abort.

Sending 10, 100-byte ICMP Echos to 150.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 150.1.4.4

!!!!!!!!!!

Success rate is 100 percent (10/10), round-trip min/avg/max = 8/8/12 ms

All right, both our tunnels are up.

Now we will configure Hairpinning and allow EZVPN users through the L2L tunnel.

Hairpininnig Configuration ASA:

access-list 122 extended permit ip 20.0.0.0 255.255.255.0 10.0.0.0 255.255.255.0

(The interesting traffic should also include traffic from 20.0.0.0/24 subnet which is the pool we are assigning to our users)

same-security-traffic permit intra-interface

(Since both VPNs terminate on outside interface, we have to use this command to allow traffic to enter and exit through outside interface)

R4:

ip route 10.0.0.0 255.255.255.0 136.1.123.12

(Because of RIP, R4 has a route towards 10.0.0.0/24 through R3 so the traffic wouldn’t traverse the tunnel. By this static route, we are forcing R4 or our EZVPN client to go through the EZVPN for the 10.0.0.0/24 subnet)

R2:

ip route 20.0.0.0 255.255.255.0 136.1.123.12

access-list 122 permit ip 10.0.0.0 0.0.0.255 20.0.0.0 0.0.0.255

(Again, the proxy ACL to allow traffic from EZVPN to traverse our L2L tunnel)

That seems all right.

Now lets test it.

but before, clear the SA’s and bring up the tunnels again.

All right, after bringing up the tunnels, here is my IPSEC SA

Rack1ASA1#

sh crypto ipsec sa | inc local ident|remote ident|encaps|decaps

local ident (addr/mask/prot/port): (136.1.121.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (10.0.0.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

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (20.0.0.1/255.255.255.255/0/0)

#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10

#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

The local ident (0.0.0.0/0.0.0.0/0/0) designates and EZVPN tunnel.

Now I will ping 10.0.0.0/24 on R4 which will traverse both tunnels

R4:

ping 10.0.0.2 source lo 0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:

Packet sent with a source address of 150.1.4.4

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 52/52/56 ms

Rack1R4#

Rack1R4#

ping 10.0.0.2 source loopback 0 rep 100

Type escape sequence to abort.

Sending 100, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:

Packet sent with a source address of 150.1.4.4

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Rack1ASA1#

sh crypto ipsec sa | inc local ident|remote ident|encaps|decaps

local ident (addr/mask/prot/port): (20.0.0.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/0/0)

#pkts encaps: 106, #pkts encrypt: 106, #pkts digest: 106

#pkts decaps: 105, #pkts decrypt: 105, #pkts verify: 105

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

local ident (addr/mask/prot/port): (136.1.121.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (10.0.0.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

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0

local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (20.0.0.1/255.255.255.255/0/0)

#pkts encaps: 115, #pkts encrypt: 115, #pkts digest: 115

#pkts decaps: 117, #pkts decrypt: 117, #pkts verify: 117

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly:

• We have an SA from 20.0.0.0 – 10.0.0.0 . It is our L2L ASA for our EZVPN traffic. The encaps and decaps and what we expected.
• The second one is our L2L SA between 136.1.121.0-10.0.0.0 networks and number of encaps decaps have not increased.
• The third is our EZVPN SA. And along with the new L2L ASA, we have packets traversing this connection as well. Which means, our EZVPN users, trying to access 10.0.0.0/24 are also traversing L2L tunnel and we have achieved our objectives.

Well folks, thats it for IPSEC hairpinning for now.

I know I am slow with the posts, but I’ve been studying for CCIE, remember?:)

I have done VOL1 INE labs and will be moving to Vol2 this week.

Also, if you stumble onto this article, please leave a comment. Tell me if you think it made any sense, or not? Was the format OK or needs something (More theory, more verification etc) and I would keep that in mind while writing the next tutorial.  And if you like the format and find the article useful, also drop in a line 🙂