Nat - strange behavior

[Dmitri Popkov]

Good day!

After i've completed my site-to-site configuration, i noticed that my nat rule - doesnt work corretly and it has a very strange behavior...

First i've tried to configru Auto nat:

object network Local-Nat

subnet 10.20.34.0 255.255.255.0

object network Local-Nat

nat (inside,outside) dynamic interface

But it didnt help....nothing happend

here is packet tracer

packet-tracer input inside icmp 10.20.34.200 1 1 8.8.8.8

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 2

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 3

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: NAT

Subtype:

Result: DROP

Config:

object network Local-Nat

nat (inside,outside) dynamic interface

Additional Information:

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Where is a mistake, can you help me please...

Thanks

[Jouni Forss · Accepted solution]

Hi,

Can you try this instead

packet-tracer input inside tcp 10.20.34.200 12345 8.8.8.8 80

And copy/paste that output here.

I think the problem might be with the code/type you chose for the ICMP. I think the ASA only creates translations for Echo and Echo Reply. The one you chose aint neither of them.

If this doesnt clear up things we might need to see the whole configuration to determine if there is some problematic NAT configuration causing issues.

- Jouni

[Akshay Dubey · Accepted solution]

Hi Dmitri,

I did a quick check on this and found that based on your config only echo request would work. If there is already a xlate entry only then it would work fine. You may try the below steps:

packet-tracer input inside icmp 10.20.34.200 8 0 8.8.8.8

packet-tracer input inside icmp 10.20.34.200 1 1 8.8.8.8

Now you would see that the second tracer would be successful. However if you do a "clear xlate" the problem will occur again.

However a manual NAT works fine in all instances.

Hope this helps

- Akshay

[Dmitri Popkov]

Ok, thanks to all of you. I've understood the packet tracert mechanism

I've solved the problem - My ISP missconfigured something...