ASA Nat problem... I'm so confused!

mikearama

I have a layered ASA approach in both UAT and PROD, so we run an external pair of ASA's which house our public IPs and nat them to the internal DMZ of Web and App servers, which are hidden behind a second pair of internal ASA's. These internal ASA's also connect to each other and the rest of the network.

I've been asked to take an internal network and NAT/PAT it before allowing it access to our APP DMZ.

I've attached a visio of the UAT layout... www.durhammods.com/UAT.vsd

Note the right side... ASA-Con1. Traffic from our internal server subnet (vlan 160) coming over the Bridgenet interface needs to access the APP servers in vlan 153, but we'd like to have the source IPs hidden to either the IP of the interface, or an IP set aside for the purpose (10.22.153.250).

Here's a quick shot of the ASA's interfaces: www.durhammods.com/ints.bmp
We're going from the Brdgnet int (level 25) to the UAT-APP int (level 50).

Because UAT-APP is the highest security level on the ASA, it has no rules applied to it outside of the implicit: www.durhammods.com/appacls.bmp

Here's the ASDM setup of the PAT from Brdgnet for 160 traffic to the UAT-APP subnet:
www.durhammods.com/nat1.bmp
(the 160 subnet is known as InternalServers/23)

Just going with that one nat statement produces this error:
www.durhammods.com/error.bmp

Suggests to me that a nat statement is required in the opposite direction... and since I don't want one, I'll go with an exempt statement:
www.durhammods.com/nat2.bmp

So now I have two statements: www.durhammods.com/nat3.bmp

No change... the "no translation" error persists.

According to cisco:
Cisco Security Appliance System Log Messages, Version 7.2 - System Log Messages [Cisco ASA 5500 Series Adaptive Security Appliances] - Cisco Systems

"Explanation: A packet does not match any of the outbound nat command rules. If NAT is not configured for the specified source and destination systems, this message may be generated frequently.

Recommended Action: This message indicates a configuration error. If dynamic NAT is desired for the source host, ensure that the nat command matches the source IP address. If static NAT is desired for the source host, ensure that the local IP address of the static command matches. If no NAT is desired for the source host, check the ACL bound to the NAT 0 ACL."

I tried to get more specific and remove the nat exemption in favour of a true dynamic nat rule with a one-to-one mapping: www.durhammods.com/nat4.bmp

This resulted in a different error:
%ASA-3-305006: portmap translation creation failed for tcp src UAT-APP:10.22.153.22/7402 dst UAT-WEB:UATWEB1/7080

Of interest, the errors did not occur with a destination of the Brdgnet interface, but all others. Makes me think that I need to put NAT statements on every interface is I add even one. I read about Nat Control in my studies... am I right that this error suggests that Nat Control is ON? And that if I turn it OFF, then I don't need to add a NAT statement everywhere?

I appreciate any insights from you ASA techies.

Mike

EDIT: I just checked, and NO NAT-CONTROL is in the config... it was never changed from the default (which is off).

dtlokee

are all sessions initiated from the higher security level interface to the lower security level interface?

rossonieri#1

hi mike,

agreed with dt,
does the traffic look like this?

Brdgnet (25) ---ASA-->[PAT] UAT (50)

do you have any problem accessing the UAT from your current config aside from the no translation error?

AFAIK, the NAT 0 means you dont need to have NAT to access the UAT network from the Brgdnet.

mikearama

dtlokee wrote: »

are all sessions initiated from the higher security level interface to the lower security level interface?

No guys... the traffic starts in the lowest security level, and tries to access the APP interface, which is the highest. Exactly like your sketch, rossonieri.

The rules are in place, and the traffic flows without the NATting in place. It's working fine right now, but the app (unix) guys are complaining about seeing the true source IPs, which they don't want. It's only with the addition of the NATting that the errors appear.

Hope that helps.

rossonieri#1

hi mike,

The rules are in place, and the traffic flows without the NATting in place. It's working fine right now, but the app (unix) guys are complaining about seeing the true source IPs, which they don't want. It's only with the addition of the NATting that the errors appear.

ok, since its already work - i could not recommend any workaround.
but, what your unix admin complaining about probably your NAT/PAT did not work at all - or, your route simply worked because you've allowed the Brdgnet to the UAT by some ACL or something.

if you cant NAT/PAT your Brdgnet facing to the UAT net, then you can try lab it up to use the reverse direction = UAT --- ASA --->[PAT] Brdgnet

dtlokee

Seems like you need to configure outside PAT for this to work along with an access-list to allow the traffic in the lower security level interface. Configuring standard dynamic PAT will not allow new session to be established from the lower security interface to a higher one.