Changing from a dynamic PAT to static NAT for external access

[heather.burke]

Although I am still not entirely sure that our Dynamic PAT is the root of the problem, it seems prudent to explore changing this to

a static value.  I have changed this to a static object, and we seem to still have outside connectivity, which is great.  One difference I notice is that after making this change, I can no longer ping my external switch, or anything beyond it.   If I were to leave this static rule in, would it still be correct to leave it using the external interface IP for its translation, or would it be better to give it a routable address from the external subnet?

Another interesting thing I noticed during this troubleshooting process is that just to see if it made a difference, I added a inside interface outgoing rule.  I noticed no difference in my problem.  So I took it back out.  However, when I removed it, suddenly nothing would work again until I added it back in.  Anyone know why this would happen?

Thanks for any help.

[Federico Coto Fajardo]

Hi,

Normally dynamic PAT is what you will use for external access so everybody shares the same IP for outbound traffic.

Static NAT is used for inbound access to servers hosted in the network.

Static NAT can be used for outbound access since it's bidirectional.

i.e.

ip nat inside source static 1.1.1.1 2.2.2.2

The above static NAT will translate always traffic received to 2.2.2.2 to 1.1.1.1 and viceversa.

Traffic can be initiated from the outside to 2.2.2.2, and 1.1.1.1 can initiate outbound traffic getting translated to 2.2.2.2

For dynamic PAT, the connections are always unidirectional.

If you have dynamic PAT for outbound connections, then traffic can only be initiated outbound.

On ASAs there's a clear NAT order that is followed where static NAT takes precedence over dynamic PAT, however on routers you might need to deny the static traffic on the dynamic rules.

Federico.

[heather.burke]

My understanding of dynamic PAT is that is still uses whatever ip address you selected (the external interface in this case)

but it connects using a variable port.  My concern in this case is that I have a specific update that is not taking place, and because it requires a special port (5721) I am concerned that perhaps the dynamic PAT is interfereing.

[Panos Kampanakis]

Just to clarify, PAT translates the source port of a packets.

So if inside host 10.10.10.10 is sourcing a TCP packet from port 1234 destined to destination x.x.x.x on port 5721, that packet is going to be translated to source being the PATter ip (outside interface) and some random port and destined to x.x.x.x again. on port 5721. So if the inside client is going out destined to that port and NOT sourced then PAT is probably not your issue.

I would suggest to use the capture option and capture the packets for the application on the outside interface to get a better idea about what is happening.

I hope it helps.

PK

[heather.burke]

That's interesting, thanks!

That's part of the question about whether or not it needs to be the same port both as source and as dest for teh program to work correctly  (I have yet to get a response from them about this)

I have not been able to get anything to show up when I do the packet capture wizard.  I'm not sure if I am doing something wrong when I run it though.  Do I put the same destination ip for both ingress and egress?  I have been leaving the source as any.

[Panos Kampanakis]

You can put as source and destination only the destination server ip address.  tha should catch bidirectional traffic to the server which will include the application traffic.

I hope it helps.

PK

[heather.burke]

oh, I hadn't been pushing the "get capture buffer".  I've also been running wireshark, but interestingly it does not show me much traffic at all when I make these requests.  I'm not entirely sure what I am looking for this way, though.  It does mention that the source port on some of the connections to that ip address are 4738.  What other information can I glean that might help me to troubleshoot this issue?

Thanks again!

[Panos Kampanakis]

You need to capture the packets in and out of the firewall. Check to see if you can see the requests hitting the inside.

Also check the logs if connections are built and the reason if they are torn down. Grep for syslogs at level 7 with the destination ip address in them

I hope it helps.

PK