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

ASA 5510 NAT confusion

Trying to implement proper NAT/Access control with the Cisco ASA 5510 and am a bit confused.  I've bought the Cisco Press books for the ASA/Pix and they are helpful but I'm still not sure exactly how to implement.  I've also contacted Cisco directly and there have been some issues in getting this resolved.  Here goes...

I have webservers/ftp servers on my DMZ (ETH port 2).  I'm able to have access from the inside to the outside work just fine (Dynamic NAT affecting internal 172.16.112.0 network and using outside interface's IP).  I also have NAT rules for the DMZ servers bound to external IP's.  All of that is working just fine.  My problem lies in having internal users access the DMZ servers via either the outside IP of that server or the DNS name.  I see that DNS Doctoring should take care of this - however - since I'm in a test environment I don't have a DNS server setup for this scenerio.  If I try to access the webserver using the external IP (which is NOT the firewall's IP - we have a bank of external IP's we can use) - it fails.  I'm confused on what the proper NAT rule(s) should be.  We are coming from the Symantec Gateway world and never had to setup NAT for internal to the DMZ - and the books I have are a bit confusing.  Any help would be appreciated!!!
0
entserv
Asked:
entserv
  • 5
  • 3
  • 2
1 Solution
 
grbladesCommented:
Normally you would just have a 'static' command to disable NAT between the internal network and the DMZ.
For example if your internal network is on 10.1.1.x you would have something like :-

static (inside,dmz) 10.1.1.0 10.1.1.0 netmask 255.255.255.0 0 0

See http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00800941c8.shtml for an example.
0
 
grbladesCommented:
If you then want to use dns doctoring there is a guide to configuring it at http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807968c8.shtml
0
 
entservAuthor Commented:
Thanks for the responses!  Well, I currently thought I DID have NAT disabled from the internal to DMZ.  I had my static statement as:

static (inside,dmz) 172.16.112.0 172.16.112.0 255.255.255.0

That worked fine when I tried to address the DMZ server by it's internal address.  However, trying to access it via the external address it would fail.  In the time I've posted this Cisco called.  They said I needed a NAT rule from the DMZ to the inside as such:

static (DMZ, inside) tcp (external IP) http 192.168.2.2 http netmask 255.255.255.255

Voila - that works - for accessing the external IP from inside.  However, this then broke trying to bring it up in a browser using 192.168.2.2 from the inside.  Now, would I ever need to do this - I really don't know.  I'm just wondering if it is something I should be concerned about?  

DNS doctoring does appear to be what I need when addressing it via DNS names.  Right now I'm in a test environment and didn't set up DNS.  But I know we'll be addressing it both ways (or, rather, some people would require both I'm sure).
0
Become a Leader in Data Analytics

Gain the power to turn raw data into better business decisions and outcomes in your industry. Transform your career future by earning your MS in Data Analytics. WGU’s MSDA program curriculum features IT certifications from Oracle and SAS.  

 
lrmooreCommented:
Fundamental problem when trying to access a natted host by its public IP address. It can't be done both ways at the same time.
DNS doctoring requires that the dns server reside somewhere outside the firewall so that the ASA sees the dns request and the response and can examine the response and translate the public back to the private IP.
If you have internal DNS (and you should), then dns doctoring won't work.
All your internal DNS servers should resolve the web site to the private IP address.
External DNS servers should resolve the web site to the public IP address.
Roaming clients never know the difference.
Problem solved.
0
 
entservAuthor Commented:
That does make sense.  We do have internal DNS but are just forwarding all external requests to our ISP's DNS.  So we should ideally change it so our websites point in our DNS to the internal IP's?  We've not done that before but it does makes sense.  I was worried it might cause some other unknown problems somehow - especially for testing purposes?
0
 
lrmooreCommented:
I would not change the dns settings for the web server. Leave it pointing to external dns.
Just make sure that on  your internal DNS server you create a zone for yourdomain.com and include the www with the native private ip address. This way, all internal users will resolve www.yourdomain.com to the private IP while they are inside your network. When outside the network, www.yourdomain.com will resolve to the public IP address and everyone is happy.
0
 
entservAuthor Commented:
Agreed - I'll do just that.  Thank you both for all your help
0
 
entservAuthor Commented:
We actually tried Cisco's approach - which was to NAT from the outside IP's to the inside for those outside IP's.  That works - it allows us to reference our DMZ servers from the inside by the DNS name - which uses the external IP's -  although it's very confusing.  Problem is - we had a NAT rule from the inside to the DMZ basically disabling it (as mentioned above).  Now internally if we try to access a server on the DMZ with it's internal IP - it fails.  In the logs it says 'no translation group available'.  It appears there is a conflicting NAT issue by having a NAT from the Outside to the Inside.  Is there any possible reason we wouldn't want to do what was mentioned above - have our internal DNS resolve to the DMZ's internal addresses?
0
 
lrmooreCommented:
> Is there any possible reason we wouldn't want to do what was mentioned above - have our internal DNS resolve to the DMZ's internal addresses?
No reason. This is actually the prefered solution.
0
 
entservAuthor Commented:
One issue I've been having with this solution is one with VPN's - site-to-site and AnyConnect.  Since both of those will use our internal DNS for resolution that poses another problem.  Our site-to-site vpn's allow us to put the dmz subnet in - and that works - but only for a time.  Eventually access to the DMZ won't work - and we don't know why.  If we reboot the box it works great.  Since they are using our DNS it is an issue - we had to resort to hosts files to get that to work.  AnyConnect is a little different in that even if we give access via a filter to the dmz it still needs a special NAT translation since it considers it Outside access (at least that's what I remember).  Even if we do split tunnelling the AnyConnect users will still see the DNS Zone on our internal DNS and try to resolve to the DMZ.  Any thoughts?  (Hopefully this isn't too confusing!)
0

Featured Post

Veeam and MySQL: How to Perform Backup & Recovery

MySQL and the MariaDB variant are among the most used databases in Linux environments, and many critical applications support their data on them. Watch this recorded webinar to find out how Veeam Backup & Replication allows you to get consistent backups of MySQL databases.

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