*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