asa dns doctoring

7/31/2019 ASA DNS Doctoring

1/20

IP Neworking, Security and a bit of funA blog where we discuss anything and everything regarding neworking, with emphasis on security for now

IPSec HairpinningPosted on November 7, 2009 | 3 Comments

Well, no I am no t love with hair pinning, but come to think of it, this c an be a useful feature .

For ex ample, your remote sites are site-site VPNs to y our HQ and you are at home, using remote

acce ss VPN to access the HQ. It would be nice , if y ou co uld access the remote sites as well, wouldnt it

?

Our scenario or rather mission is such.

IPSEC Hairpinning Topology

We want to create a L2 L VPN between ASA and R2 to encry pt traffic between 10.0.0.0/24 and

136.1.121 .0/24 network.

Then we want users to acce ss from R4, our ASA using EZVPN and these users should be allowed to

25/04/2011 IP Neworking, Security and a bit of fun

http://iptechtalk.wordpress.com/ 1/20


2/20

send encry pted traffic ov er the already created L2L VPN. Static routes are permitted for this

configuration.

All dev ices are running RIP v er 2 and hav e full reac h-ability to each othe r.

NAT-Control is not enable on A SA.

Also , the topology is similar to I NE Remote access VPN labs, except, I hav e put R4 in VLAN 100

instead o f a test PC.

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

Configuration:

ASA:

crypto isakmp policy 1 0

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.1 21.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 12 2

crypto map IMAP 5 set peer 136.1 .23.2

!




3/20

crypto map I MAP interface outside

R2:

crypto isakmp policy 1 0

authen pre-share

group 2

hash md5

encryption 3des

!

crypto isakmp key 0 CISCO address 136.1 .1 23.1 2

!

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

!

acce ss-list 122 permit ip 10 .0.0.0 0.0.0.255 1 36.1.1 21.0 0.0 .0.255

!

crypto map IMAP 5 isakmp-ipsec

set transform-set T_SET

match address 1 22

set peer 136.1.1 23.12

!

int S0/1

crypto map IMAP

!

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




4/20

Here is th e 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-protoc ol ipsec

address-po ols v alue LOCAL_POOL

!

tunnel-group EZVPN type remote -acce ss

tunnel-group EZVPN ipsec-attributes

pre-shared-key CISCO

tunnel-group EZVPN ge neral-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 1 00 set reverse-route

crypto map IMAP 20 ipsec-isakmp dynamic D_MAP

!

router rip




5/20

redistribute static

!

R4 EZVPN remote (Client):

crypto ipsec c lient ezvpn EZVPN

group EZVPN key CISCO

connect auto

mode client

peer 136.1 .1 23 .1 2

int lo0

crypto ipsec c lient ezvpn EZVPN inside

!

int fa0/0

crypto ipsec c lient ezvpn EZVPN outside

!

We test both tunnels

For L2L:

R2:

ping 136.1 .1 21 .1 sourc e fa0/ 0

Sending 5, 1 00 -byte ICMP Echo s to 136.1 .1 21 .1 , timeout is 2 seco nds:

Pac ket se nt w ith a so urc e addre ss o f 10.0.0 .2

.!!!!

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

Rack1ASA1#




6/20

sh crypto ipsec sa

interface: outside

Crypto map tag: IMAP, seq num: 5, local addr: 136.1 .123.1 2

access-list 122 permit ip 136.1.1 21.0 255.255.255.0 10.0.0.0 255.255.255.0

local ident (addr/mask/prot/port): (136.1.121.0/25 5.25 5.25 5.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 c lose attentio n to IPSEC SAs to understand the difference.

Now we br ing up EZVPN tunnel and test it

Rack1R4#

crypto ipsec c lient ezvpn xauth

Username: test

Passw ord:

Rac k1R4#

Nov 6 09:33:29.20 1: %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

Rac k1R4#

Nov 6 09:33:31.084: % LINK-3-UPDOWN: Inte rface Lo opbac k1000 0, change d state to

up

Nov 6 09:33:32.086: % LINEPROTO-5-UPDOWN: Line protocol on Inte rface

Loopbac k100 00 , change d state to up

Rack1R4#

Rack1R1#

sh ip route




7/20

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

D EIGRP, EX EIGRP external, O OSPF, IA OSPF inte r area

N1 OSPF NSSA exte rnal type 1 , N2 OSPF NSSA exte rnal type 2

E1 OSPF external type 1 , E2 OSPF exte rnal 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 downloade d static route

Gateway o f last resort is not set

136.1 .0.0/24 is subnetted, 5 subnets

C 136.1 .11 .0 is directly connected, FastEthernet0/0.1 1

R 136.1 .23.0 [1 20/2 ] via 136.1 .1 21 .1 2, 00:00 :22, FastEthernet0/0.121

R 136.1 .1 00 .0 [120 /2 ] via 136.1 .1 21 .1 2, 00 :00:22, FastEthernet0/0 .1 21

C 136.1 .121 .0 is directly connected, FastEthernet0/0.1 21

R 136.1 .1 23 .0 [120/1] via 136.1 .1 21 .1 2, 00 :00:2 2, FastEthernet0/0 .1 21

20.0.0.0/3 2 is subn etted, 1 subn ets

R 20. 0. 0. 1 [120/1] via 136.1.121.12, 00:00:16, FastEth ern et0/0 .121

10 .0.0.0/24 is subnetted, 1 subnets

R 10.0.0.0 [120 /3 ] via 136.1 .1 21 .1 2, 00:00 :23, FastEthernet0/0.1 21

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:

Pac ket se nt w ith a so urc e addre ss o f 150.1 .4.4

!!!!!!!!!!




8/20

Success rate is 100 percent (1 0/10), ro und-trip min/av g/max = 8/8/1 2 ms

All right, both ou r tunn els are u p.

Now we will con figu re Hairpin ning an d allow EZVPN users through th e L2L tunn el.

Hairpininnig Configuration ASA:

acce ss-list 122 extended permit ip 20.0.0.0 255.25 5.255 .0 10.0 .0.0 255.25 5.255 .0

(The interesting traffic sho uld also include traffic from 20.0 .0.0 /24 subnet which is the poo l 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.1 2

(Because of RIP, R4 has a route to wards 10 .0.0.0 /24 through R3 so the traffic w ouldnt 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 1 36.1.123.12

acce ss-list 122 permit ip 10 .0.0.0 0.0.0.25 5 20.0.0 .0 0.0.0.255

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

That seems all right.

Now lets test it.

but before , c lear the SAs 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




9/20




#pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4

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

local ident (addr/m ask/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.25 5/0/0)

#pkts encaps: 10, #pkts encry pt: 10, #pkts digest: 10



The local ident (0.0.0.0/0 .0.0.0/0/0) designates and EZVPN tunn el.

Now I will ping 10.0 .0.0/24 on R4 which will trav erse both tunnels

R4:

ping 10.0.0 .2 sourc e lo 0


Sending 5, 1 00 -byte ICMP Echo s to 10.0.0 .2, timeout is 2 seconds:


!!!!!

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

Rack1R4#

Rack1R4#

ping 10.0.0 .2 sourc e loopbac k 0 re p 1 00





10/20

Sending 100 , 1 00 -byte ICMP Echo s to 10.0 .0.2, timeout is 2 seco nds:


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

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

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)


#pkts encaps: 106, #pkts encry pt: 106, #pkts digest: 106

#pkts decaps: 105, #pkts decry pt: 105, #pkts verify: 105







local ident (addr/m ask/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.25 5/0/0)



#PMTUs sent: 0, #PMTUs rcvd: 0 , #dec apsulated frgs needing reassembly:

We hav e an SA from 20.0 .0.0 10 .0.0 .0 . I t is o ur L2L A SA for our EZVPN traffic. The e ncapsand decaps and what we ex pected.

The second one is our L2L SA be tween 136.1 .121 .0-10.0.0.0 networks and number of encaps

decaps have not increased.

The third is our EZVPN SA. A nd along with the new L2L ASA, we hav e packets trave rsing this




11/20

connection as well. Which means, our EZVPN users, try ing to acc ess 10 .0.0 .0/24 are also

traversing L2L tunnel and we have achieve d our o bjectives.

Well folks, thats it for IPSEC hairpinning for now.

I know I am slow with the posts, but Ive been study ing for CCIE, remember?:)

I hav e done V OL1 INE labs and will be mov ing to Vol2 this week.

Also , if y ou stumble onto this artic le, please leav e 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

The need for DNS Doctoring on ASA: Methodsand WorkaroundsPosted on September 4, 2009 | 2 Comments

In a ty pical DNS ex change a client sends a URL or hostname to a DNS serv er in order to de termine

the IP address of that host. The DNS serv er rec eives the reque st, looks up the name-to-IP-address

mapping for that host , and then prov ides the A-rec ord with the IP address to the c lient. While this

proc edure works well in many situations, problems can occ ur. These problems can occ ur when the

client and the host that the client tries to reach are bo th on the same of different priv ate network

behind NAT, but the DNS server used by the c lient is on ano ther public network.

Without DNS doctoring or anothe r solution enabled in this situation, if the client sends a DNS request

for the IP address of the Web Serv er it is unable to acc ess the WWW serv er. This is bec ause the client

receives an A-reco rd that contains the mapped public address of WWW serv er. When the client tries

to acc ess this IP address, the security appliance drops the packets because it does not allow packet

redirec tion on the same interface.

There are many permutations of this issue and different o ptions to solv e 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 Doc toring.

3 Comm entsPosted in EZVPN, I PSEC VPNS, Site to Site VPN

Tagged EZVPN, IPSec Hairpinning, L2LVPN




12/20

3) Using Hairpinning and DNAT instead of DNS Doc toring.

Based on the loc ation of clients and web-serv er we c an have the following situations.

Clients and Web Serv er are both o n DMZ while DNS Serve r is a public ser v er on the Outside.

(DMZ can be c hanged with inside as the emphasis is client and Web Serv er being behind the

same interface)

Web Serv er is on DMZ and Clients are on inside.

The tutorial will show all possible ways in which the pro blem can be solv ed based on the c lients.

Well use the Test Server as c lient in b oth DMZ and use a router for DNS requests o n the inside. We

will be using the topology of InternetworkExpert[i] and though the Lab Workboo k 1 has two

ex cellent labs on the topic, well go further and include all possible scenarios.

TOPOLOGY:

Well use the test serv er as inside as well as on DMZ zone to simulate clients.

SCENARIO 1:

USING THE ALIAS COMMAND FOR DNS DOCTORING AND DNAT:

First, lets describe the difference between the two.

DNS Doctoring pe rforms two functions:

Translates a public address (the routable or mapped address) in a DNS reply to a priv ate

address (the real address) when the DNS client is on a priv ate interface.

Translates a priv ate address to a public address when the DNS client is on the public interface.

While DNAT or Destination NAT has the following func tio ns




13/20

In dnat, the A SA changes the destination IP of an application call from one IP address to

another IP address.

This process is used when y ou want the actual application call from the internal client to the

serv er in a perimeter (dmz) network by its exter nal IP address. This does not docto r the DNS

replies.

So for Clients on the DMZ, we would use DNS Doc toring and for Clients on inside, we will use DNAT.

Technically the c onfiguration will be same, but its important to understand whats actually happeninghere.

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-CONTROLnat (inside) 1 0 0

nat (dm z) 1 0 0

global (outside) 1 interface

static (dm z,ou tside) 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 h ost WWW 136.1.122.100

Now well make the Test Serv er in inside V LAN first and Then in DMZ and Try to reach the WWW

serv er after DNS resolution from R2:

int fa 0/20

swit acc v lan 120

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




14/20

As y ou can see the DNS serv er is resolv ing the IP to 136.1 .1 22.1 00 which the published IP.

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

R1:

ip dom ain lookup

ip name-server 136.1.122.2

Rack1R1#ping WWW

T ranslating WWWdomain serv er (136.1.122.2) [OK]


T y pe escape sequence to abort.

Sending 5 , 100-by te ICMP Echos to 136.1.122.100, tim eout is 2 seconds:

..

Success rate is 0 percent (0/5)

Now well use the DNS Doctoring and DNAT and test again. Well change the te st serv er to inside zone

and repeat the testing proc ess.

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




15/20

sysopt noproxy arp inside

sysopt noproxy arp dmz

Now on R1:

Rack1R1#ping WWW



Sending 5, 100-by te ICMP Echos to 10.0.0.100, tim eout is 2 seconds:

..


As we can see, now the serv er name is resolv ed to DMZ address 1 0.0.0.1 00, for clients on DMZ and

inside Zone and there is no need for re direct ion on outside interface anymore. The ping is not

allowed bec ause 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.

Y ou can have multiple alias commands tied to different interfaces on the same ASA

SCENARIO 2:

USING STATIC WITH DNS KEYWORD FOR DNS DOCTORING:

Remov e the prev ious Alias commands.




16/20

Now well use the Static command with DNS keywo rd to solve the issue.

For c lients on the DMZ well need this command as we need DNS Doctoring. But remember we used

alias for Destination NAT prev iously for clients on inside. In this case, with static co mmand we will

not need to do an anything for c lients 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 .10 0, so both c lients on inside and DMZ

will be able to access the host using the priv ate IP add ress.

Here is the configuration

clear con figure alias

no static (dmz,outside) 136.1.122.100 10.0.0.100 netm ask 255 .255.255.255

static (dm z,outside) 136.1.122.100 10.0.0.100 dns netm ask 255 .255.255.255

Here is the verification .

Rack1R1#ping WWW



Sending 5, 100-by te ICMP Echos to 10.0.0.100, tim eout is 2 seconds:

..


Rack1R1#

And on th e client




17/20

SCENARIO 3:

USING HAIRPINNING AND DNAT INSTEAD OF DNS DOCTORING.

Remember the main raison deter o f the alias command is that ASA do esnt allow the pac ket

redirec tion on same interface. What if we can c hange this behavior?

This wasnt possible in earlier v ersions (and if you ask me, it shouldnt be as its a serious secur ity

breach). But Cisco bowing to the demands of customers and in order to match checkpoint allo ws this

feature now. This is called Hairpinning.

In our scenario, well do hairpinning for the c lients on DMZ and DNAT for the clients on the inside.

Here is what Ciscos website says about Hairpinning

Hairpinning is the proc ess by which traffic is sent back out the same interface on w hich it arrived.

This feature w as introduc ed 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 outbo und) 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 w hen you use 7 .2(1).

Hairpinning, in conjunctio n with a static NAT statement, can be used to achie ve the same e ffect as

DNS docto ring. This method do es not change the c onte nts of the DNS A-record that is returned from

the DNS server to the client.

For c lients on inside, well simply publish the pub lic address o f our WWW serv er by using static

command.

Here is th e configuration.

static (dm z,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 redirec tion on

interface)




18/20

global (dm z) 1 interface (nat-co ntrol is enabled. Traffic go ing to DMZ must be Natted)

static (dm z,dm z) 136.1.122.100 10.0.0.100

static (dm z,inside) 136.1.122.100 10.0.0.100

For T esting:

access-list DMZ_IN permit ip any any

access-group DMZ_IN in interface dm z

Here is the v erification.

Rack1R1#telnet WWW 80


T rying WWW (136.1.122.100, 80) Open

HTT P/1.1 400 Bad Request

Server: Microsoft-II S/5.0

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

Content-T ype: text/html

Content-Length : 87

ErrorT he param eter is inc orrect.

[Connection to WWW closed by foreign host]

As you can see, even thou gh th e DNS resolv es to 136.1.122.100, R1 is able to reach .

Similarly for hosts in DMZ




19/20

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

[i] Copy righted topology -The writer o f this blog has obtained permission from Mr.Brian and Mr.Peter

to use the topology or diagram as reference.

IntroductionPosted on July 13, 2009 | 1 Comm ent

2 Comm entsPosted in ASA, DNS Doctoring

Tagged ASA, DNAT, DNS Doctoring, Security




20/20

Hello I am Barooq , CCIE # 22087 .

I kept a blog at http://ccie-chronicles.blogspot.comand also wrote some articles on

http://www.cciecandidate.comduring my ccie R/s preperation.

After a hiatus spanning over 8 months, I am back in the game. Pre pering for my CCIE sec urity ( The

effort has just begun).

I shifted from blogspot for two reasons

1) I want this blog to be about netwo rking in general, not cc ie prep particularly .

2)Lets face it, blogspot suc ks:)

I will be writing tutorials and general tech talk, predominantly about security related topics (CCIE

and general) and will also include my observ ations, whatever intersting subject I enco unter during

the prep and at work etc.

I am using INE produc ts (Workboo ks only). I hav e always heard great things about COD, but ev en

after the grac ious discount, it was out of my reac h.

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

Peace to all

Theme: Coraline by Automattic Blog at WordPress. com.

1 Comm entPosted in Uncategorized

Tagged General, Introduction


asa dns doctoring

Documents