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

Without DNS doctoring or another solution enabled in this situation, if the client sends a DNS request for the IP address of the Web Server it is unable to access the WWW server. This is because the client receives an A-record that contains the mapped public address of WWW server. When the client tries to access this IP address, the security appliance drops the packets because it does not allow packet redirection on the same interface.

There are many permutations of this issue and different options to solve it. Mainly, we can summarize the solution in following three methods

1)      Using Alias command for DNS Doctoring or Destination NAT

2)      Using Static with DNS Keyword for DNS Doctoring.

3)      Using Hairpinning and DNAT instead of DNS Doctoring.

Based on the location of clients and web-server we can have the following situations.

• Clients and Web Server are both on DMZ while DNS Server is a public server on the Outside. (DMZ can be changed with inside as the emphasis is client and Web Server being behind the same interface)
• Web Server is on DMZ and Clients are on inside.

The tutorial will show all possible ways in which the problem can be solved based on the clients.

We’ll use the Test Server as client in both DMZ and use a router for DNS requests on the inside. We will be using the topology of InternetworkExpert[i] and though the Lab Workbook 1 has two excellent labs on the topic, we’ll go further and include all possible scenarios.

Topology:

We’ll use the test server as inside as well as on DMZ zone to simulate clients.

Scenario 1:

Using the Alias Command for DNS Doctoring and DNAT:

First, let’s describe the difference between the two.

DNS Doctoring performs two functions:

• Translates a public address (the routable or mapped address) in a DNS reply to a private address (the real address) when the DNS client is on a private interface.
• Translates a private address to a public address when the DNS client is on the public interface.

While DNAT or Destination NAT has the following functions

• In dnat, the ASA changes the destination IP of an application call from one IP address to another IP address.
• This process is used when you want the actual application call from the internal client to the server in a perimeter (dmz) network by its external IP address. This does not “doctor” the DNS replies.

So for Clients on the DMZ, we would use DNS Doctoring and for Clients on inside, we will use DNAT. Technically the configuration will be same, but its important to understand whats actually happening here.

Configuration and Explanation:

As First step, we will not configure the DNS Doctoring and simulate the issue. This will be our basic configuration on ASA.

ASA1:

Nat-control

nat (inside) 1 0 0

nat (dmz) 1 0 0

global (outside) 1 interface

static (dmz,outside) 136.1.122.100 10.0.0.100

static (inside,dmz) 136.1.121.0 136.1.121.0 netmask 255.255.255.0

access-list OUT_IN permit ip any any

access-group OUT_IN in interface outside

R2:

ip dns server

ip host WWW 136.1.122.100

Now we’ll make the Test Server in inside VLAN first and Then in DMZ and Try to reach the WWW server after DNS resolution from R2:

int fa 0/20

swit acc vlan 120

In IE topology, the Test server is connected with SW2F0/20

As you can see the DNS server is resolving the IP to 136.1.122.100 which the published IP.

The problem with this resolution is that ASA will drop the traffic.

R1:

ip domain lookup

ip name-server 136.1.122.2

Rack1R1#ping WWW

Translating “WWW”…domain server (136.1.122.2) [OK]

Translating “WWW”…domain server (136.1.122.2) [OK]

Type escape sequence to abort.

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

…..

Success rate is 0 percent (0/5)

Now we’ll use the DNS Doctoring and DNAT and test again. We’ll change the test server to inside zone and repeat the testing process.

alias (dmz) 10.0.0.100 136.1.122.100 255.255.255.255

alias (inside) 10.0.0.100 136.1.122.100 255.255.255.255

sysopt noproxyarp  inside

sysopt noproxyarp  dmz

Now on R1:

Rack1R1#ping WWW

Translating “WWW”…domain server (136.1.122.2) [OK]

Type escape sequence to abort.

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

…..

Success rate is 0 percent (0/5)

As we can see, now the server name is resolved to DMZ address 10.0.0.100, for clients on DMZ and inside Zone and there is no need for redirection on outside interface anymore. The ping is not allowed because on DMZ interface ICMP is dropped. But DNS resolution is what we want

Also on our client

Some Notes:

Other Configuration Notes

• The interface in the alias command needs to be the “interface” that the clients call from.
• You can have multiple alias commands tied to different interfaces on the same ASA

Scenario 2:

Using Static with DNS Keyword for DNS Doctoring:

Remove the previous Alias commands.

Now we’ll use the Static command with DNS keyword to solve the issue.

For clients on the DMZ we’ll need this command as we need DNS Doctoring. But remember we used alias for Destination NAT previously for clients on inside. In this case, with static command we will not need to do an anything for clients on the inside as dns keyword will take care of that. Because the DNS reply will be changed at the outside interface to 10.0.0.100, so both clients on inside and DMZ will be able to access the host using the private IP address.

Here is the configuration

clear configure alias

no static (dmz,outside) 136.1.122.100 10.0.0.100 netmask 255.255.255.255

static (dmz,outside) 136.1.122.100 10.0.0.100 dns netmask 255.255.255.255

Here is the verification.

Rack1R1#ping WWW

Translating “WWW”…domain server (136.1.122.2) [OK]

Type escape sequence to abort.

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

…..

Success rate is 0 percent (0/5)

Rack1R1#

And on the client

Scenario 3:

Using Hairpinning and DNAT instead of DNS Doctoring.

Remember the main raison deter of the alias command is that ASA doesn’t allow the packet redirection on same interface. What if we can change this behavior?

This wasn’t possible in earlier versions (and if you ask me, it shouldn’t be as it’s a serious security breach). But Cisco bowing to the demands of customers and in order to match checkpoint allows this feature now. This is called Hairpinning.

In our scenario, we’ll do hairpinning for the clients on DMZ and DNAT for the clients on the inside. Here is what Cisco’s website says about Hairpinning

“Hairpinning is the process by which traffic is sent back out the same interface on which it arrived. This feature was introduced in security appliance software version 7.0. For versions earlier than 7.2(1), it is required that at least one arm of the hairpinned traffic (inbound or outbound) be encrypted. From 7.2(1) and later, this requirement is no longer in place. Both the traffic inbound and the traffic outbound might be unencrypted when you use 7.2(1).

Hairpinning, in conjunction with a static NAT statement, can be used to achieve the same effect as DNS doctoring. This method does not change the contents of the DNS A-record that is returned from the DNS server to the client.”

For clients on inside, we’ll simply publish the public address of our WWW server by using static command.

Here is the configuration.

static (dmz,outside) 136.1.122.100 10.0.0.100 netmask 255.255.255.255

static (inside,dmz) 136.1.121.0 136.1.121.0 netmask 255.255.255.0

same-security-traffic permit intra-interface (Enables Hairpinning and redirection on interface)

global (dmz) 1 interface (nat-control is enabled. Traffic going to DMZ must be Natted)

static (dmz,dmz) 136.1.122.100 10.0.0.100

static (dmz,inside) 136.1.122.100 10.0.0.100

For Testing:

access-list DMZ_IN permit ip any any

access-group DMZ_IN in interface dmz

Here is the verification.

Rack1R1#telnet WWW 80

Translating “WWW”…domain server (136.1.122.2) [OK]

Trying WWW (136.1.122.100, 80)… Open

HTTP/1.1 400 Bad Request

Server: Microsoft-IIS/5.0

Date: Fri, 04 Sep 2009 18:43:11 GMT

Content-Type: text/html

Content-Length: 87

<html><head><title>Error</title></head><body>The parameter is incorrect. </body></html>

As you can see, even though the DNS resolves to 136.1.122.100, R1 is able to reach .

Similarly for hosts in DMZ

I hope this tutorial is useful of the non-existent reader base of this blog J

I kept a blog at http://ccie-chronicles.blogspot.com and also wrote some articles on http://www.cciecandidate.com during my ccie R/s preperation.

After a hiatus spanning over 8 months, I am back in the game. Prepering for my CCIE security ( The effort has just begun).

I shifted from blogspot for two reasons

1) I want this blog to be about networking in general, not ccie prep particularly.

2)Lets face it, blogspot sucks:)

I will be writing tutorials and general tech talk, predominantly about security related topics (CCIE and general) and will also include my observations, whatever intersting subject I encounter during the prep and at work etc.

I am using INE products (Workbooks only). I have always heard great things about COD, but even after the gracious discount, it was out of my reach.

Hopefully, my first tech post will be there somewhre this week:)

Peace to all