firewall nat rule

[Kashish_Patel]

Hi Security Experts,

I am facing a weird problem.

Firewall is learning route on outside interface, but packet tracer shows that a packet destined to that IP is being sent out on inside interface.

The packet should come on remote1 interface and should go out outside interface, but running packet tracer on firewall shows that it matches nat rule between inside and remote1 interface and sends packet out on inside interface, which is wrong.

Phase: 3

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

nat (inside,remote1) source static any any destination static obj-149.77.0.0 obj-149.77.0.0

Additional Information:

NAT divert to egress interface inside

Untranslate 205.231.107.2/0 to 205.231.107.2/0

[Kashish_Patel]

I don't see ROUTE-LOOKUP field anywhere in the packet tracer. Why is firewall not doing route lookup and just solely passing traffic based on nat?

[varrao]

Hi Kashish,

To troubleshoot it, you would need to provide:

The source and the destination address

The source and destination interface

The packet tracer command that you used

Outputs of "show run nat"

Remember, this is post 8.3 configuration that you are using, so nat rules are hit first in it.

Thanks,
Varun Rao
Security Team,
Cisco TAC

[Kashish_Patel]

Varun,

Sent you all the outputs as a private message. Let me know what you find.

[varrao]

Hi Kashish,

The issue are these conflicting nat statements:

nat (inside,remote1) source static any any destination static obj-149.77.0.0 obj-149.77.0.0

nat (inside,remote1) source static any any destination static obj-205.231.96.0 obj-205.231.96.0

nat (inside,outside) source static any any destination static obj-149.77.0.0 obj-149.77.0.0

nat (inside,outside) source static any any destination static obj-205.231.96.0 obj-205.231.96.0

It tells me that both the networks can be reached through remote1 as well as outisde interface, which is not correct. In 8.3 or higher natting, the nat search is done from top to bottom, so the as soon as firewall hits a matching rule, it would take that.

My suggestion to you would be to make your nats very specific rather than keeping them so open.

Let me know if you have any questions.

Thanks,
Varun Rao
Security Team,
Cisco TAC

[Kashish_Patel]

Varun,

That makes sense. Actually I am little confused about how to interpret the nat statement, say

nat (inside,remote) source static any any destination static obj-10.10.0.0 obj-10.10.0.0

What does it say?

A packet received on inside interface will not be translated when it is going out on remote interface destined to 10.10.0.0 network, right? The above statement also tells that 10.10.0.0 network resides on remote interface, correct?

Now how about when a packet is received on remote interface sourced from an  IP in 10.10.0.0 network. Will this packet *ALWAYS* get forwarded to inside interface as per the above statement?If yes, then the above statement is bidirectional, right?

[Kashish_Patel]

>>It tells me that both the networks can be reached through remote1 as well as outisde interface, which is not correct.

But as per the packet capture output that I sent you, firewall is forwarding packet ( destined to 205.231 network) on inside interface and not on remote1/outside. I am confused

[Kashish_Patel]

Varun,

Can you also tell me order of execution of nat, ACL and route-lookup?

Which happens first while forwarding packets through ASA?

Thanks,

Kashish

[varrao]

Hi Kashish,

Answer to your first post:

Yes the nat works bi-directional. But the question is why do you have such an open /16 network defined, make it more specific, probably a /24 network to segregate your two networks behind different interfaces. Moreover, it would be better idea not to have same network addresses behind two different interfaces on the ASA.

Nats should be created, when you have a very specific source network and destination network to be defined, so that the traffic hits only that statement. Now I am not sure how your network addressing is done but make sure you do not have the same network IP's behind different interfaces.

In 8.4 software, your order of ooperation would be, NAT---> ACL----> Route-lookup

The packet would first be un-translated, then the acl would be checked, and then routed through the correct destination interface.

Thanks,
Varun Rao
Security Team,
Cisco TAC

[Kashish_Patel]

>>But the question is why do you have such an open /16 network defined,  make it more specific, probably a /24 network to segregate your two  networks behind different interfaces. Moreover, it would be better idea  not to have same network addresses behind two different interfaces on  the ASA.

We have this ASA running for years and IP address scheme was laid out  long back. Now because ASA has changed its behavior, we are required to  put specific nat statements. This will be too tiring for us

Actually we were running 8.2(2)16 code before and we did not face any issue. I noticed that ASA was taking forwarding decisions based on route-lookup in 8.2.

Problems are happening on 8.4(4)1. And that is because default ASA behavior has changed. I have gone through the release notes that you mentioned in another post, but this default ASA behavior just does not make sense