ASA 8.2(5) NAT Question

rrfield · ‎11-03-2011

I'm sure this has been covered, but I have been unable to find the answer.

I am in the testing phase of a project that will replace another vendor's firewall with an ASA running 8.2(5).

Basic topology: Inside, Outside, DMZ1, DMZ2. Everything is operating as expected - dynamic interface PAT to outside interface for outbound traffic, NAT0 for inside to DMZ traffic, static NATs for publicly available DMZ services.

The problem is, a handful internal users have grown acoustom to using the public IP addresses for certain functions. I've been unable to get the NAT settings correct to make this work. I'd like to be able to use both the Public and DMZ IP addresses from the Inside. Is this possible? The other vendor supports this.

I tried doing a simple static translation from the DMZ to the Inside, but received an error about asymetric NAT (due to the NAT0 coming from the DMZ's back to the Inside I assume).

Here's my current NAT config (sanitized)...

------------------

ciscoasa(config)# sh run nat-control

nat-control

!

ciscoasa(config)# sh run same-security-traffic

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

!

ciscoasa(config)# sh run global

!

global (Outside) 1 interface

!

ciscoasa(config)# sh run nat1

!

nat (DMZ1) 0 access-list dmz1_nat0_outbound outside

nat (DMZ1) 1 0.0.0.0 0.0.0.0

!

nat (DMZ2) 0 access-list dmz1_nat0_outbound outside

nat (DMZ2) 1 0.0.0.0 0.0.0.0

!

nat (Inside) 0 access-list inside_nat0_outbound

nat (Inside) 1 0.0.0.0 0.0.0.0

!

ciscoasa(config)# sh run static

!

static (DMZ1,Outside) 50.50.50.50 192.168.1.50 netmask 255.255.255.255

static (DMZ2,Outside) 50.50.50.111 192.168.2.111 netmask 255.255.255.255

!

ciscoasa(config)#

----------------

and a generic topology drawing...

Thanks in advance...

Kureli Sankar · ‎11-03-2011

The problem is, a handful internal users have grown acoustom to using  the public IP addresses for certain functions.

That is bad idea. Is there a way you can change that? Because, that is the right thing to do.

We do have ways to get around it but, that will not be the right way to fix it.

There is something called DNS doctoring that would work - provided the DNS request for the same server on the DMZ goes thorugh the firewall and we have dns inspection enabled on the firewall.

You can read here:

-Kureli

rrfield · ‎11-03-2011

Yeah I know it's a bad idea.

Changing human behaviour is much more difficult than any technical solution, 10 times out of 10.

We take care of most of this by resolving the public hosts names to the DMZ addresses with split DNS, but it doesn't always work out that way.

There are some applications that use the IP address. 50.50.50.50. Not a DNS name, so any DNS-centric soultions are out. It's a hassle, but I can only control so much. Other vendors do this with no problem, the ASA should be able to handle this without tricks.

One idea I had was to split the ASA cluster into two contexts, which is a trick and shouldn't be necessary. It also limits our functionality - can't terminate VPN's anymore.

caseth0102 · ‎11-03-2011

Not sure if I'm understanding your requirements here. Can you state why it is necessary for your inside host/s to communicate with the external IP's of the DMZ hosts? They are all connected to the same firewall. I propose, you simply add 1-1 statics for the entire inside to DMZ1 and DMZ2. Then just use the interface ACLs to control traffic. What is the purpose of trying to communicate from inside to a public address? Testing?

rrfield · ‎11-03-2011

Look, I agree that it's unnecessary, however it happens. Our developers end up hard coding public IP addresses (instead of DNS names) into web pages hosted on the "inside", they instruct internal users to FTP to public IP addresses (instead of the DMZ IP or DNS hostname)...it drives me nuts, but it's reality.

I'll expirament with the Statics and see if I can get acceptable results, thanks for the idea.

Kureli Sankar · ‎11-03-2011

I hear you. I have been there. I had the developers change the code to use names.

Anyway, in your case since they are using IP address from the inside DNS doctoring will not work.

You need D-NAT.

static (dmz,inside) public_ip dns_side_real_IP

Let me know if this works.

-Kureli

rrfield · ‎11-03-2011

Interesting.

Here's what I did...

!

! first, got rid of the nat0's from Inside to DMZ and DMZ to Inside, then...

!

access-list 192-168-1-50 extended permit ip host 192.168.1.50 any

!

access-list 192-168-1-50_pub extended permit ip host 192.168.1.50 any

!

static (DMZ,Outside) 50.50.50.50 192.168.1.50 netmask 255.255.255.255

static (DMZ,Inside) 192.168.1.50 access-list 192-168-1-50

static (DMZ,Inside) 50.50.50.50 access-list 192-168-1-50_pub

!

Didn't work.

...I am testing with a 5505, 8.2(5)...

ciscoasa(config)# sh run interface | beg Vlan

interface Vlan100

nameif Outside

security-level 0

ip address 50.50.50.1 255.255.255.0

!

interface Vlan101

nameif DMZ

security-level 50

ip address 192.168.1.1 255.255.255.0

!

interface Vlan102

nameif Inside

security-level 100

ip address 10.1.1.1 255.255.255.0

!

ciscoasa(config)# int Vlan102

ciscoasa(config-if)# sec

ciscoasa(config-if)# security-level 40

ciscoasa(config-if)#

Now it works from the Inside, using both 192.168.1.50 and 50.50.50.50.

Downside, the DMZ interface security-level is higher than Inside.

What problems am I going to run into if I keep it this way?

EDIT: I wasn't planning on relying on security-levels for access control, but rather by applying interface ACL's like Jean Claude mentioned.

Message was edited by: Richard Field

Kureli Sankar · ‎11-03-2011

Pls. don't complicate things with policy etc than what it already is.

You need the following:

static (inside,dmz) inside_real_IP inside_real_IP --- source address translation

static (dmz,inside) dmz_public_IP dmz_real_IP --- destination address translation

let me know if it works.

-Kureli

rrfield · ‎11-03-2011

I've tried multiple iterations of this, the only thing that works is removing the nat0's, then applying your config...but then this will only work between the two hosts I am testing with. I can't do this for each of the 100's of potential hosts that require this!

This is nuts. Why can all the other firewall vendors handle this, but the ASA cannot?

Would upgrading to 8.3/8.4 help?

caseth0102 · ‎11-03-2011

Just knock the DMZ security-level down below that of the inside interface. No issues, but would be good practice to make sure the 'most trusted networks' sec-lvls are higher than the DMZ.

rrfield · ‎11-03-2011

Jean Claude, if I make the DMZ interface sec-lev lower than Inside, the config above breaks.

Kureli Sankar · ‎11-03-2011

I've tried multiple iterations of this, the only thing that works is removing the nat0's, then applying your config...but then this will only work between the two hosts I am testing with. I can't do this for each of the 100's of potential hosts that require this!

This is nuts. Why can all the other firewall vendors handle this, but the ASA cannot?

Would upgrading to 8.3/8.4 help?

The sample source nat and D-NAT that I gave you was assuming inside is higher security than dmz.

Anyway, upgrading to 8.3 wouldn't help either. You would have more lines to configure when compared to pre 8.3 NAT that you have.

I am not sure what other firewall vendors you are talking about. I am sure they don't all do everything that our ASA firewall does.

At this point since there are multiple hosts involved, it would be better to open a TAC case - also to ease your frustration. Depending on all the public addresses may be we can come up with a subnet address instead of individual hosts for D-NAT static.

-Kureli

rrfield · ‎11-03-2011

I think what I'm going to end up doing is

1) configure the ASA's as originally intended

2) place a spare 5505 between Inside and DMZ with NAT's setup to do what is required

3) route necessary public addresses to the 5505

4) Log and monitor all traffic and get the developers to use the internal addresses and instruct helpdesk to use internal addresses (which, as everyone here agrees, is the best long term solution).

Sorry about my frustration level, we are migrating from a Juniper/Netscreen and it handles this with no issues. Checkpoint does as well. I apprecite the marketing plug, though

Kureli Sankar · ‎11-04-2011

get the developers to use the internal addresses and instruct helpdesk to use internal addresses

That is not a good idea. If I were to load this page from outside of your company then, these internal private addresses are going to fail.

The best thing to do is use name. When the inside users try the pages, have the inside DNS server hand the internal/private IP addresses. When the external (folks on the internet) try to access the page, their local DNS servers will hand the routable IP address.

-Kureli

rrfield · ‎11-04-2011

You are right, dns name is better.

So it looks like the Nat0 attached to the DMZ1 interface was the problem all along. I removed that and added the two Static Policy NAT's from earler and everything seems to be working, no 2nd firewall necessary...I think this is where Jean Claude's suggestion was leading. Also used a subnet static like Kureli suggested, staying away from Static Policy if at all possible.

nat-control

! works with no nat-control also in this simple config

!

same-security-traffic permit inter-interface

same-security-traffic permit intra-interface

!

object-group network Inside_Nets

network-object 10.1.1.0 255.255.255.0

!

access-list inside_nat0_outbound extended permit ip object-group Inside_Nets 192.168.1.0 255.255.255.0

!

nat (DMZ1) 100 0.0.0.0 0.0.0.0

nat (Inside) 0 access-list inside_nat0_outbound

nat (Inside) 100 0.0.0.0 0.0.0.0

!

global (Outside) 100 interface

!

static (DMZ1,Outside) 50.50.50.50 192.168.1.50 netmask 255.255.255.255

static (DMZ1,Inside) 192.168.1.0 192.168.1.0 netmask 255.255.255.0

static (DMZ1,Inside) 50.50.50.50 192.168.1.50 netmask 255.255.255.255

!

I have some more testing to do with more security zones (like the DMZ2 mentioned in the original question), but I think this is the right direction.

I still think all these hoops are silly, but it's working. Thanks for the leads towards the right config!