• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 709
  • Last Modified:

Help troubleshooting NAT entry (with DNS doctoring)

I have the following entries for a 1:1 NAT statement, that sits on a hosted firewall upstream from us:

access-list outside_acl extended permit tcp any host 74.85.0.202 eq ssh
access-list outside_acl extended permit tcp any host 74.85.0.202 eq www
access-list outside_acl extended permit tcp any host 74.85.0.202 eq https
access-list outside_acl extended permit icmp any host 74.85.0.202 echo-reply
access-list outside_acl extended permit icmp any host 74.85.0.202 echo
access-list outside_acl extended permit tcp any host 74.85.0.202 eq 3306
static (inside,outside) 74.85.0.202 10.102.84.15 netmask 255.255.255.255 dns

Open in new window


we manage the DNS servers for our company, and in the primary DNS zone, I have a simple "A" record for a FQDN to point to the above static IP, 74.85.0.202

test.abc.com.           	900     IN	A       74.85.0.202

Open in new window


so we can access this FQDN internally, in the office, we have to have the "DNS doctoring" statement in order to properly resolve the FQDN back to the private IP.

the only thing that changed over the weekend is, we have a managed-ethernet/EoC connection that utilizes a Hatteras device, and that device failed this weekend. Yesterday we had it replaced, and now we are back to using the EoC connection. That's it.

I verified w/ the hosting company that the DNS doctoring keyword does exist, as you can see by the statements posted above.

I'm at a loss why this isn't working now. any ideas where to check and/or how to resolve?

I can ping this box from our datacenter, by hostname.

64 bytes from 74.85.0.202: icmp_seq=1 ttl=54 time=10.1 ms

Open in new window


internally pinging the hostname resolves back to 10.102.84.15; trying to resolve FQDN through browser though just dies
0
kapshure
Asked:
kapshure
  • 3
  • 2
1 Solution
 
patternedCommented:
When you manually put that private address in the browser address bar, what happens?

If you can ping via hostname, this isn't a DNS issue, and what I previously alluded to will not work either.

You did not say if the internal pinging was successful or not.  I'll assume it was...
Is there a firewall in between the devices?
VLANs?
Is the box running the web server have port 80 open?
etc, etc.
0
 
kapshureAuthor Commented:
it was the latter! dev issue! i ran nmap on it saw that 80/443 wasn't open. hopped on the box, did a
ps - ef | grep httpd 

Open in new window


and confirmed..  checked also with
netstat -at | grep 80

Open in new window

and
netstat -at | grep 443

Open in new window

.. no dice!

started httpd, bam.

/sigh.

thanks though!
0
 
kapshureAuthor Commented:
dev's hadn't started httpd!
0
 
patternedCommented:
I love when I forget the dumb things.  Just a little nudge is all you needed.


Damn devs! ;)
0
 
kapshureAuthor Commented:
yeh, i just assumed they had their sh!t together. "ass-u-me" DOH!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now