Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

*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 192.168.7.1 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 192.168.1.1 the dns reply is doctored to give me the public ip on the 91.x.x.x range, not the 10.1.16.34 ip.


                10.1.0.x
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 192.168.0.0 255.255.240.0 10.1.16.0 255.255.252.0 
access-list inside_nat0 extended permit ip 192.168.7.0 255.255.255.224 192.168.0.0 255.255.240.0 
access-list inside_nat0 extended permit ip 192.168.0.0 255.255.240.0 192.168.7.0 255.255.255.224 

//added to fix
access-list outside_nat0 extended permit ip 192.168.7.0 255.255.255.224 10.1.16.0 255.255.252.0 
access-list outside_nat0 extended permit ip 10.1.16.0 255.255.252.0 192.168.7.0 255.255.255.224



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

static (dmz,outside) 91.x.x.x 10.1.16.34 netmask 255.255.255.255 dns tcp 1000 100 udp 1000 
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  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
share|improve this question
    
can you show your policy-maps? –  3molo Jul 15 '11 at 10:25
    
sure I've added them to the initial question –  gilesw Jul 15 '11 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 '11 at 14:38
add comment

2 Answers

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.

share|improve this answer
add comment
up vote 1 down vote accepted

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.

share|improve this answer
    
Please mark this answer as correct! –  3molo Jul 18 '11 at 14:12
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.