Bypassing the global nat

[Krishna Chandrashekar]

Hi,

One of my customer wants to by pass the global nat configured as below and needs static nat to take preference, please help me out with the suggestion, should i remove the global configuration or is there any other work around.Also this is production envirorment removing the global configuration can cause an outage.

Here is the configuration.

Hostname= sh run | i ntlonasr905

name 172.16.96.12 ntlonasr905

name 204.8.151.171 ntlonasr905-NAT

static (inside,DTCC) ntlonasr905-NAT ntlonasr905 netmask 255.255.255.255

Hostname# sh run nat

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 2 access-list inside_nat_outbound

nat (inside) 3 access-list inside_nat_outbound_1

nat (inside) 4 access-list inside_nat_outbound_2

nat (inside) 1 0.0.0.0 0.0.0.0

global (DTCC) 1 204.8.151.129 netmask 255.255.255.255

Regards,

Krishna

[Jouni Forss]

Hi,

Static NAT is in a higher priority than any Dynamic NAT/PAT or Dynamic Policy NAT/PAT.

The only thing listed above that could override it is the NAT0 configuration but as we are talking about a private IP address on the actual server then I doubt it configured with NAT0 with a destination "any"

You should be able to determine if the Static NAT works with the following command

packet-tracer input inside tcp 172.16.96.12 12345 1.1.1.1 80

This should simulate a packet entering the "inside" interface with the source IP address that is used in your Static NAT.

It should tell us what NAT rule it uses when it heads to some example destination IP address on the public network.

Share the output of the above command with us.

- Jouni

[Krishna Chandrashekar]

Hi,

Please find the output,

packet-tracer input inside tcp 172.16.96.12 12345 1.1.1.1 80

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         inside

Phase: 3

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

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

Please  reply ASAP, can we clear the xlate table as well for this particular  global ip, also we have a memory issue for this device, will this impact  if we clear the xlate table

[Jouni Forss]

Hi,

I am not sure why a destination IP address of 1.1.1.1 would be located behind your "inside" interface unless you have a default route pointing towards your "inside" interface for some reason?

This is what the "packet-tracer" is telling us atleast.

The following command will list all configured routes

show run route

- Jouni

[Krishna Chandrashekar]

Hi,

Yes we have default route towards the inside interface. Here is the output.

sh run route

route inside 0.0.0.0 0.0.0.0 10.48.65.250 1

route TNS 208.224.251.0 255.255.255.0 10.48.75.46 1

route DTCC 167.188.68.0 255.255.255.0 10.48.75.69 1

route DTCC 207.45.34.0 255.255.255.0 10.48.75.69 1

route DTCC 207.45.47.0 255.255.255.192 10.48.75.69 1

route DTCC 207.45.47.101 255.255.255.255 10.48.75.69 1

route DTCC gtr-ny-prod 255.255.255.255 10.48.75.69 1

route DTCC gtr-ny-uat 255.255.255.255 10.48.75.69 1

route DTCC DTCC-FTP-01 255.255.255.255 10.48.75.69 1

route DTCC DTCC-FTP-02 255.255.255.255 10.48.75.69 1

route caliso 10.48.75.16 255.255.255.240 10.48.75.3 1

route UTSP-Fidessa 12.182.174.0 255.255.255.0 10.48.75.99 1

route UTSP-Fidessa 12.192.234.0 255.255.255.0 10.48.75.99 1

route UTSP-Fidessa 65.244.97.0 255.255.255.0 10.48.75.99 1

route Loanet-DMZ Loanet-Test-Server-1 255.255.255.255 Loanet-NY-Router 1

route Loanet-DMZ Loanet-Server-1 255.255.255.255 Loanet-NY-Router 1

route Loanet-DMZ Loanet-SFTP-Server-2 255.255.255.255 Loanet-NY-Router 1

route Loanet-DMZ Loanet-SFTP-Server-1 255.255.255.255 Loanet-NY-Router 1

route Loanet-DMZ SLB19B-loanet-public 255.255.255.255 Loanet-NY-Router 1

route Loanet-DMZ Sloan-Server-2 255.255.255.255 Loanet-NY-Router 1

route Loanet-DMZ SLB19A-loanet-public 255.255.255.255 Loanet-NY-Router 1

route Loanet-DMZ Sloan-Server-1 255.255.255.255 Loanet-NY-Router 1

route Loanet-DMZ 65.215.31.138 255.255.255.255 Loanet-NY-Router 1

route Loanet-DMZ 208.252.13.10 255.255.255.255 Loanet-NY-Router 1

route Loanet-DMZ Loanet_LFA 255.255.255.255 Loanet-NY-Router 1

route Broadridge-DMZ 149.83.42.119 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ 167.212.3.0 255.255.255.0 10.48.75.180 1

route Broadridge-DMZ TN3270E-Server-1 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ Broadridge-149-83-1-13 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ Broadridge-149-83-1-66 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ Broadridge-149-83-28-219 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ Broadridge-149-83-96-31 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ Broadridge-149-83-96-32 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ Broadridge-149-83-96-33 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ 149.83.28.220 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ 149.83.28.221 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ 149.83.1.11 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ 149.83.1.12 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ 149.83.1.63 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ Broadridge-MQ-Server 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ 149.83.81.48 255.255.255.255 10.48.75.180 1

route Broadridge-DMZ 149.83.188.48 255.255.255.255 10.48.75.180 1

Problem is when the traffic goes from inside to DTCC it is patting instead of static, please advise.

Regards

Krishna

[Jouni Forss · Accepted solution]

Hi,

Static NAT should always override a Dynamic NAT/PAT.

When you configured the Static NAT for this host, did you clear the translations for the local IP address?

clear xlate local 172.16.96.12

This might naturally teardown all connections of that host when you do it.

You can check the existing translations for that host with

show xlate local 172.16.96.12

or with

show xlate | inc 172.16.96.12

Could you provide a "packet-tracer" output where you use the servers source IP address and some destination IP address for which the Dynamic PAT is happening?

So basically

packet-tracer input inside tcp 172.16.96.12 12345

- Jouni

[Krishna Chandrashekar]

We can clear the xlate but memory utilization is high as 96%, can we go ahead clearing the xlate even though the memory is high?. Please suggest on this

Krishna

[Jouni Forss]

Hi,

You dont have to clear all translations/xlates on the firewall.

The above command

clear xlate local

Only clear an xlate/translation for a single local IP address.

If your constant memory usage is at that level I would highly recomend considering replacing your current firewall model with some higher end model from the current one. Perhaps even look into possibility of upgrading the memory on the unit. Or perhaps look into cleaning up the configuration to free up some memory.

- Jouni