• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

ASA 5510 DMZ issue

P

Pantlegz

Diamond Member
for whatever reason I'm not able to get my DMZ(webserver) to get DNS information from my domain. I have the security of the inside interface set to 100 and the DMZ is set to 50 I made an access list to allow traffic from the DMZ to my DNS server and there it's getting hits. I also made sure it works otherwise, I can get to google with the ip address, which means my NATing is working properly.

So if my DMZ can talk to my DNS server, what else would I need to do to get this to work correctly? I'm kinda lost at this point...

It appears that it's an issue getting information from my inside interface to my DMZ, I added a deny any any to the end of both access lists and it's got like 60 hits after trying to hit google on my webserver, but I have no idea what it would be blocking... any ideas?
 
Last edited:
yes they're being NATed. Well actually they're being PATed but I've made sure it's working correctly and as far as I can tell it is.
 
Pantlegz1 said:
yes they're being NATed. Well actually they're being PATed but I've made sure it's working correctly and as far as I can tell it is.
Click to expand...
How do you have your web server setup? Do you have a public IP address mapped to the DMZ IP address or do you just setup port redirection, i.e., does your ASA and web server use the same public IP address or are they using different public IP addresses?

EDIT: Disregard. I thought the problem was with the DMZ and the Internet.
 
Last edited:
nslookup times out, no servers could be contacted. It's being PAT'ed from the outside everything is seen as one IP. Both the DMZ and my inside interface are using private addresses.
 
If you are NATing from the DMZ, you might be having trouble with a missing "nat 0" list for other traffic. The packet-tracer command is pretty helpful for simulating whether something will get through the ASA, also make sure you have a log buffer enabled (use debug level temporarily if necessary) and check your logs when you try the DNS lookup.

If you feel like sharing your config (or some anonymized version) I may be able to provide more insight.
 
The only thing I can think of what may be happening is the inside interface is NATing or not NATing (depending on the setup) the response back from the DNS server to the DMZ. Are you using NAT from the inside to the DMZ?
 
Last edited:
Pheran said:
If you are NATing from the DMZ, you might be having trouble with a missing "nat 0" list for other traffic. The packet-tracer command is pretty helpful for simulating whether something will get through the ASA, also make sure you have a log buffer enabled (use debug level temporarily if necessary) and check your logs when you try the DNS lookup.

If you feel like sharing your config (or some anonymized version) I may be able to provide more insight.
Click to expand...

Thank you oh so much, I knew it had to be something simple that I had forgotten about. I didn't add the DMZ address to my no nat 0 acl. Sucks wasting 3 hours on one stupid command...
 
I have another similar issue, that I'll just throw in the same thread instead of making a new one. I'm able to get to the webserver from the internet by name but internally I'm only able to access it by IP. And the funny thing is it's not, or at least shouldn't, be a DNS issue. I've manually entered an A record for the webserver in the DMZ and nslookup for the domain gives me the correct address.

However no page can be displayed, I've checked the logs on the ASA and I've come up with this "No translation group found for tcp src inside:192.168.3.2/53533 dst DMZ:172.16.0.2/80" Where 192.168.3.2 is the computer attempted to access the web server at 172.16.0.2. Any ideas on whats going on here?
 
I have another similar issue, that I'll just throw in the same thread instead of making a new one. I'm able to get to the webserver from the internet by name but internally I'm only able to access it by IP. And the funny thing is it's not, or at least shouldn't, be a DNS issue. I've manually entered an A record for the webserver in the DMZ and nslookup for the domain gives me the correct address.

However no page can be displayed, I've checked the logs on the ASA and I've come up with this "No translation group found for tcp src inside:192.168.3.2/53533 dst DMZ:172.16.0.2/80" Where 192.168.3.2 is the computer attempted to access the web server at 172.16.0.2. Any ideas on whats going on here?
 
there are no translations to facilitate that communication. you have to remember the PIX is not a router...for traffic to flow from a high security level interface to a lower security interface, there must be corresponding nat and global statements. for the reverse direction there must be corresponding static and access-list statements.

as pheran said, post a sanitized configuration.
 
Last edited:
Code: 
hostname ASA
domain-name matc1.matc.net

names
dns-guard

interface Ethernet0/0
 nameif outside
 security-level 0
 ip address 10.13.4.1 255.255.0.0

interface Ethernet0/1
 nameif inside
 security-level 100
 ip address 192.168.4.1 255.255.255.0

interface Ethernet0/2
 nameif DMZ
 security-level 50
 ip address 172.16.0.1 255.255.0.0

interface Management0/0
 shutdown
 no nameif
 no security-level
 no ip address


ftp mode passive
clock timezone CST -6
clock summer-time CDT recurring 1 Sun Apr 2:00 last Sun Oct 2:00
access-list 101 extended permit tcp any any eq www
access-list 101 extended permit tcp any any eq domain
access-list 101 extended permit udp any any eq domain
access-list 101 extended permit tcp any any eq pptp
access-list 101 extended permit tcp any any eq smtp
access-list 101 extended permit tcp any any eq 995
access-list 101 extended permit tcp any any eq https
access-list 101 extended permit esp any any
access-list 101 extended deny ip any any
access-list inside_nat0_outbound extended permit ip any 192.168.254.0 255.255.255.240
access-list inside_nat0_outbound extended permit ip any host 172.16.0.2
access-list 102 extended permit tcp any any eq www
access-list 102 extended permit tcp any any eq domain log
access-list 102 extended permit udp any any eq domain log
access-list 102 extended deny ip any any log
access-list 103 extended permit tcp any any eq www log
access-list 103 extended permit tcp any host 192.168.3.2 eq domain
access-list 103 extended permit udp any host 192.168.3.2 eq domain
access-list 103 extended permit tcp any any eq domain log
access-list 103 extended permit udp any any eq domain log
access-list 103 extended deny ip any any log
pager lines 24
logging enable
logging buffered informational
mtu outside 1500
mtu inside 1500
mtu DMZ 1500
ip local pool RemoteAccess 192.168.254.1-192.168.254.10 mask 255.255.255.0
asdm image disk0:/asdm-507.bin
no asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 192.168.0.0 255.255.0.0
nat (DMZ) 1 172.16.0.0 255.255.0.0
static (inside,outside) tcp interface domain 192.168.3.2 domain netmask 255.255.255.255
static (inside,outside) udp interface domain 192.168.3.2 domain netmask 255.255.255.255
static (inside,outside) tcp interface smtp 192.168.3.4 smtp netmask 255.255.255.255
static (inside,outside) tcp interface 995 192.168.3.4 995 netmask 255.255.255.255
static (inside,outside) tcp interface https 192.168.3.4 https netmask 255.255.255.255
static (DMZ,outside) tcp interface www 172.16.0.2 www netmask 255.255.255.255
static (DMZ,inside) tcp 70.239.244.15 www 172.16.0.2 www netmask 255.255.255.255
static (inside,DMZ) tcp 172.16.0.2 www 70.239.244.15 www netmask 255.255.255.255
access-group 101 in interface outside
access-group 102 in interface DMZ
route outside 0.0.0.0 0.0.0.0 10.13.1.254 1
route inside 192.168.0.0 255.255.0.0 192.168.4.2 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute

 dns-server value 192.168.3.2 192.168.3.3
 default-domain value matc1.matc.net
 webvpn

http server enable
http 0.0.0.0 0.0.0.0 inside
snmp-server host inside 192.168.2.10 trap community topsecret
snmp-server location topsecret
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-SHA
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map interface outside

telnet timeout 5
ssh timeout 5
console timeout 0

class-map inspection_default
 match default-inspection-traffic

policy-map global_policy
 class inspection_default
  inspect dns maximum-length 512
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect netbios
  inspect rsh
  inspect rtsp
  inspect skinny
  inspect esmtp
  inspect sqlnet
  inspect sunrpc
  inspect tftp
  inspect sip
  inspect xdmcp

service-policy global_policy global
ntp server 199.240.130.1 source outside prefer

: end
ASA#

there's the running config, partially sanitized.
 
you shouldn't need any nat0 statements...apply an ACL on the DMZ interface to permit the traffic and create a static translation as such:

static (inside,DMZ) 192.168.3.2 192.168.3.2 netmask 255.255.255.255

if you're still having problems or want to see the traffic that isn't being permitted, look at the ACL logging.
 
Last edited:
the NAT0 is for vpn, I just pulled all the vpn stuff out. the traffic is permited, I can get there by IP but the name is giving me issues. I thought it was DNS but I have an A record with the name/ip of the webserver in my DNS server and nslookup shows it's getting the correct ip address.
 
jlazzaro said:
there are no translations to facilitate that communication. you have to remember the PIX is not a router...for traffic to flow from a high security level interface to a lower security interface, there must be corresponding nat and global statements. for the reverse direction there must be corresponding static and access-list statements.

you shouldn't need any nat0 statements...apply an ACL on the DMZ interface to permit the traffic and create a static translation as such:

static (inside,DMZ) 192.168.3.2 192.168.3.2 netmask 255.255.255.255

if you're still having problems or want to see the traffic that isn't being permitted, look at the ACL logging.
Click to expand...

Sorry, but this is completely wrong for ASA/PIX version 7+ unless you have nat-control enabled. Nat-control is an evil relic from the PIX era that should be left off. Modern ASAs will route just fine without all this identity NAT nonsense as long as the ACLs permit the traffic.
 
Last edited:
Pantlegz, I don't have time right now to study your problem/config in detail but I will try to take a look this evening.
 
OK, so I've been able to take a general look at your config and I have some questions and comments.

1. Why is there static NAT configuration between inside and the DMZ? Unless there's a very good reason for this, NATing internally is just ugly and should be avoided.

2. Your nat 0 list looks weird to me (and it may be causing trouble - "any" can be dangerous there). I would have just used:

access-list NONAT permit ip 192.168.0.0 255.255.0.0 172.16.0.0 255.255.0.0
access-list NONAT permit ip 172.16.0.0 255.255.0.0 192.168.0.0 255.255.0.0

That should cover all the internal traffic that doesn't need to bother with NAT.

3. Is your DNS server properly resolving split-DNS for the internal and external views of your web server? If you are only using 1 DNS server for everyone, it needs to be set up to resolve your web server address as your ASA outside IP for external clients and 172.16.0.2 for internal clients (using BIND views for example).

4. This is probably not relevant to your problem, but the "inspect dns maximum-length 512" config is not a good idea. Unfortunately it is the default, but newer DNS standards use larger packets than that (see RFC 2671). I normally set mine to 1300.
 
Last edited:
You must log in or register to reply here.

TRENDING THREADS

Back
Top