cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1948
Views
0
Helpful
5
Replies

Why i could not ping (icmp) after changing the NAT public ip address

Lasandro Lopez
Level 1
Level 1

Hi there!
i've a ASA 5510, with several interfaces.
I've a public IP address 1.1.1.1 on interface Ethernet0, it is configured as outside

INSIDE interface is on ethernet 1, and has ip address 192.168.1.1/24

i've allowed internet access from intenal user to external, and i use dynamic nat, and the translated IP address is IP address of interface Ethernet0 1.1.1.1.

In this moment, the internal user could browse normally to internet (http, https, ftp etc...) also could use icmp to test public internet addresses like 8.8.8.8 of google for example.

but, from ISP, i've some other IP addresses (1.1.1.1 up to 1.1.1.5)

and when i make an inside host, let say 192.168.1.8, with dynamic nat to Public IP address 1.1.1.2, the internal host could not ping anymore outside hosts, but have normal internet connection. When i see the public IP of this host (using www.whatismyip.com) it shows correctly the IP 1.1.1.2
Why this happen? and how to fix this issues?

Regards!

5 Replies 5

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Since you have not provided any configurations could you use the "packet-tracer" command to simulate the ICMP sent by the host that is now using a different NAT IP address.

For example

packet-tracer input INSIDE icmp 8 0 8.8.8.8

This should atleast confirm what rules/configurations the host connection attempt is matching.

- Jouni

see picture below!

hope it helps

Hi,

The above ASDM "packet-tracer" doesnt really correspond to what I was asking above.

The ICMP type/code used in the "packet-tracer" is wrong and is most probably the reason it results in a drop.

The "packet-tracer" command used on the CLI of the ASA is a lot clearer output than using the ASDM.

The situation/problem would be a lot more clearer if either you didnt have ICMP Inspection enabled which seems to be enabled or if no other connections would either work from the hosts using the other NAT IP address.

Could you use the original "packet-tracer" I used on the CLI and copy/paste the output here. Naturally you should change any public IP address visible in the output.

- Jouni

CISCOASA# packet-tracer input INSIDE icmp 192.168.1.8 8 0 8.8.8.8

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         OUTSIDE

Phase: 4     

Type: IP-OPTIONS

Subtype:     

Result: ALLOW

Config:      

Additional Information:

Phase: 5     

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:      

Additional Information:

Phase: 6     

Type: NAT    

Subtype: host-limits

Result: ALLOW

Config:      

static (INSIDE,ISP02) tcp interface www 192.168.1.8 www netmask 255.255.255.255

  match tcp INSIDE host 192.168.1.8 eq 80 ISP02 any

    static translation to 192.168.3.3/80

    translate_hits = 0, untranslate_hits = 13

Additional Information:

Phase: 7     

Type: NAT    

Subtype:     

Result: ALLOW

Config:      

nat (INSIDE) 2 192.168.1.8 255.255.255.255

  match ip INSIDE host 192.168.1.8 OUTSIDE any

    dynamic translation to pool 2 (1.1.1.2)

    translate_hits = 3237, untranslate_hits = 807

Additional Information:

Dynamic translate 192.168.1.8/0 to 1.1.1.2/49583 using netmask 255.255.255.255

Phase: 8     

Type: FLOW-CREATION

Subtype:     

Result: ALLOW

Config:      

Additional Information:

New flow created with id 86632032, packet dispatched to next module

Phase: 9     

Type: ROUTE-LOOKUP

Subtype: output and adjacency

Result: ALLOW

Config:      

Additional Information:

found next-hop 1.1.1.5 using egress ifc OUTSIDE

adjacency Active

next-hop mac address 588d.09b5.1cc0 hits 50042

Result:      

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: OUTSIDE

output-status: up

output-line-status: up

Action: allow

Hi,

Well there should be no problem related to ARP/Routing atleast if other connections from host using this new public IP address is working.

Also, if you have ICMP Inspection configured then it ICMP should work for all internal hosts or none at all.

You could check "show run policy-map" command output and see if there is "inspect icmp" and "inspect icmp error" under it.

If not, then you could add

fixup protocol icmp

fixup protocol icmp error

- Jouni

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: