*Update, turns out that adding additional nat exclusions stopped dns doctoring from being triggered, resolving the problem.

So I have one last outstanding issue with our vpn setup to our office.

I can successfully vpn in and get allocated an ip on the outside interface. I can then ssh to any of our machines on the inside 192.168.x.x range without any problem. However when I make a dns request for one of our dmz hosted machines to our internal dns server on the dns reply is doctored to give me the public ip on the 91.x.x.x range, not the ip.

192.168.x.x        dmz             91.x.x.x
[inside    | cisco asa 5510| outside]
                                 |allocated 192.168.7.x
                              [cisco vpn client]

Here are the pertinent lines from our IOS config.

access-list inside_nat0 extended permit ip 
access-list inside_nat0 extended permit ip 
access-list inside_nat0 extended permit ip 

//added to fix
access-list outside_nat0 extended permit ip 
access-list outside_nat0 extended permit ip

nat (inside) 0 access-list inside_nat0
nat (inside) 1
nat (outside) 1
nat (dmz) 2
//added to fix
nat (outside) 0 access-list outside_nat0
nat (dmz) 0 access-list outside_nat0

static (dmz,outside) 91.x.x.x netmask dns tcp 1000 100 udp 1000 
class-map inspection_default
 match default-inspection-traffic
policy-map type inspect dns preset_dns_map
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map 
  inspect ftp 
  inspect h323 h225 
  inspect h323 ras 
  inspect rsh 
  inspect rtsp 
  inspect esmtp 
  inspect sqlnet 
  inspect skinny  
  inspect sunrpc 
  inspect xdmcp 
  inspect sip  
  inspect netbios 
  inspect tftp 
  inspect icmp 
service-policy global_policy global
  • can you show your policy-maps?
    – 3molo
    Jul 15, 2011 at 10:25
  • sure I've added them to the initial question
    – gilesw
    Jul 15, 2011 at 12:51
  • As I see it service policies can only be applied on a interface basis which means the vpn which is terminated on the outside will always get doctoring because of dns reply will come from the inside to the outside interface. However when a user is actually on the inside interface in the office their dns traffic won't ever hit the outside interface because the dns server is on their same physical interface.
    – gilesw
    Jul 15, 2011 at 14:38

2 Answers 2


Well, the client's on the outside interface - DNS doctoring is behaving exactly as intended, really.

Do you actually need DNS doctoring enabled on that translation? Are you serving public DNS from an internal server with the internal addresses, and just having doctoring catch that address on the way out the door?

If not, then just tear the dns off of your static line and you're all set.

If so, consider setting up a DNS server that just serves public DNS.

If you're set on keeping doctoring enabled, then I can think of one ugly workaround that should do it: two policy static translations - one for when the destination is internal with DNS doctoring disabled, then a lower priority one with doctoring enabled. Like I said: ugly.


Turns out that just by adding additional nat exclusions this disabled the dns doctoring. Essentially all traffic from the outside interface that is in the vpn ip pool needs to identified as no-nat to talk to the dmz and the inside interfaces correctly.

  • Please mark this answer as correct!
    – 3molo
    Jul 18, 2011 at 14:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .