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

ICMP response from interface IP instead of NATed IP

n.zernov21
Level 1
Level 1

Hello everyone! We have configured WAN and NAT on router the following way:

interface GigabitEthernet0/0/0
 description WAN
 ip address 185.160.91.40 255.255.255.0
 ip nat outside
! ip nat pool SS-INET 185.160.91.251 185.160.91.251 prefix-length 24 ip nat pool ITSH-INET 185.160.91.32 185.160.91.32 prefix-length 24 ip nat inside source list 50 interface GigabitEthernet0/0/0 overload ip nat inside source list 51 pool ITSH-INET overload ip nat inside source list 52 pool SS-INET overload ! ip route 0.0.0.0 0.0.0.0 185.160.91.1 ! access-list 50 permit 10.1.0.0 0.0.0.255 access-list 51 permit 10.30.1.0 0.0.0.255 access-list 51 permit 10.30.2.0 0.0.0.255 access-list 52 permit 10.1.1.0 0.0.0.255

The router has been working with this configuration for about a year and now we've ran into some major problem: when I am trying to ping NATed addresses I get response from interface IP:

PING 185.160.91.251 (185.160.91.251): 56 data bytes
64 bytes from 185.160.91.40: icmp_seq=0 ttl=255 time=0.937 ms
64 bytes from 185.160.91.40: icmp_seq=1 ttl=255 time=0.880 ms

 

ASR1002 with ESP5

Cisco IOS XE Software, Version 03.13.10.S - Extended Support Release

 

5 Replies 5

Hello,

 

the ICMP NAT translation timeout is 60 seconds, set that to:

 

ip nat translation icmp-timeout never

 

That would ensure that you can always ping the pool address...

Problem is not in ICMP. This led to packet loss and somethings request timeout.

Hello,

 

there are numerous NAT timeouts that expire after 60 seconds by default:

 

finrst-timeout

port-timeout tcp

port-timeout udp

syn-timeout

 

I don't know which traffic exactly is affected in your case, but try to set all these values to never expire:

 

ip nat translation finrst-timeout never

ip nat translation port-timeout tcp never

ip nat translation port-timeout udp never

ip nat translation syn-timeout never

Hi @n.zernov21,

1. What if you do:

interface GigabitEthernet0/0/0
ip address 185.160.91.251 255.255.255.0 secondary

2. Are you originating that ping test from a:

a. host located behind this Gig0/0/0 with ip nat outside,

b. host behind an interface with ip nat inside,

c. Router itself,

d. where exactly?

3. The Router creates a 185.160.91.251/32 as a L - local entry in Routing Table only when traffic is originated by a host in the 10.1.1.0/24 based on your configuration. You won't be able to ping 185.160.91.251 for traffic hitting the ip nat outside if translations are not there because that L - local entry wouldn't be created.

Try configuring 185.160.91.251 as 'secondary' on your WAN interfaces as suggested in point #1.

 

Cheers.

After 2 days of debugging it seems to be a route redistribution problem on separate BGP router.
Review Cisco Networking for a $25 gift card