Static NAT/PAT failing....need help

[burleyman]

Let's say there is a outside IP address of 1.1.1.1 and I want to get to a piece of equipment on the
inside of the network with an IP address of 192.168.168.234 and use TCP port 3000.

So I try to go to http://1.1.1.1:3000 and get to that piece of equipment and it fails.

I try packet tracer and it shows it drops at the nat shown below....why?

Here is my config and the outside interface IP address is 1.1.1.1

object network 192.168.168.234_TCP_3000
 host 192.168.168.234
 nat (inside,outside) static interface service tcp 3000 3000

access-list outside_inbound extended permit tcp any4 object 192.168.168.234_TCP_3000 eq 3000

What is causing this not to work?

Mike

[Karsten Iwen]

The config looks good. Can you please post the output of packet-tracer? And are there any logs?

What do you mean with "get to that peace of equipment"? If the NAT fails, nothing should get there.

[burleyman]

I do have this conifugred

object network NETWORK_OBJ_192.168.168.0_24
 nat (inside,outside) dynamic interface

I will gather more information in a bit.

Thanks,

Mike

[Jouni Forss]

Hi,

There should not be many reasons why the firewall would drop the connection and since you mention its related to the NAT then the one thing that comes to mind is that you might have a Dynamic PAT configuration using the "interface" IP address also. This would mean that any connection coming from external network would match that Dynamic PAT rather than the Static PAT and get dropped. Though I am not sure if the ASA would then mention this Static PAT configuration at all.

Check if you have the Dynamic PAT configured in the following way

nat (inside,outside) source dynamic any interface

This could cause problems

If you on the other hand have it configured this way

nat (inside,outside) after-auto source dynamic any interface

Then it should not be the cause of the problem.

But as Karsten said, the "packet-tracer" output should tell us more.

EDIT: Incase you used the real IP address in the "packet-tracer" command as the destination then this would atleast explain why the NAT fails and mentions the Static PAT configurations. This would make the test fail the RPF Check. Meaning it would not match the same NAT configuration in both directions of the connection. But this DROP would only be a result of a mistake in the "packet-tracer" command. It might even be that the local device is blocking the connection in this case.

- Jouni