Why doesn't this NAT ping?

1388-2/HB · Guest

interface Ethernet0
ip address 192.168.1.3 255.255.255.248
ip nat outside

interface FastEthernet0
ip address 172.16.2.1 255.255.255.0
ip nat inside

ip nat pool 200 172.16.2.200 172.16.2.200 netmask 255.255.255.0 type rotary

ip nat inside destination list d115 pool 200

ip access-list extended d115
permit icmp any host 6.22.8.115 echo
permit tcp any host 6.22.8.115 eq 80
permit tcp any host 6.22.8.115 eq 443

If a tcp TCP packet destined for 6.22.8.115:80 arrives from the outside,
this is the NAT debug result:

NAT: o: tcp (17.81.13.141, 1725) -> (6.22.8.115, 80) [15504]
NAT: s=17.81.13.141, d=6.22.8.115->172.16.2.200 [15504]

The machine at 172.16.2.200 receives the packet, so this is working as I
would expect it to.

However if this is repeated instead with a ping to 6.22.8.115, the router
chooses not to NAT the ping. There is simply no NAT debug output for the
ping at all.

I can prove ping does arrive at the router (I can policy route it, for
example) but I cannot seem to NAT it. Is my ACL incorrect? What am I
missing?

@NOSPAMhod!SPAM.co(dot)uk · Guest

I may be barking up the wrong tree here but do you have any 'ip inspect'
rules running?

1388-2/HB wrote:

1388-2/HB · Guest

I haven't specified any 'ip inspect' rules. With the exception of ancillary
things like password, hostname, et al, what's posted is essentially the
entire config (this is a test router dedicated to troubleshooting the issue,
purposefully minimalist to reduce the variables).

Here is a particularly baffling observation (to me anyway)

With this config (distilled for brevity)

---------------------------------------------------
interface Ethernet0
ip address 192.168.1.3 255.255.255.248
ip policy route-map TestPolicy

interface FastEthernet0
ip address 172.16.2.12 255.255.255.0

imp access-list extended d115
permit icmp any host 6.22.8.115 echo
deny ip any any

route-map TestPolicy permit 10
match ip address d115
set interface FastEthernet0
---------------------------------------------------

A ping is sent to 6.22.8.115 (from outside address 17.81.13.141). 'Debug ip
policy' outputs the following:

IP: s=17.81.13.141 (Ethernet0), d=6.22.8.115, len 60, policy match
IP: route map TestPolicy, item 10, permit
IP: s=17.81.13.141 (Ethernet0), d=6.22.8.115 (FastEthernet0), len 6
0, policy routed
IP: Ethernet0 to FastEthernet0 6.22.8.115

This looks correct to me. Now, I change the config to NAT, rather than
policy route:

---------------------------------------------------
interface Ethernet0
ip address 192.168.1.3 255.255.255.248
ip nat outside

interface FastEthernet0
ip address 172.16.2.12 255.255.255.0
ip nat inside

ip nat pool 200 172.16.2.200 172.16.2.200 netmask 255.255.255.0 type rotary

ip nat inside destination list d115 pool 200

ip access-list extended d115
permit icmp any host 6.22.8.115 echo
deny ip any any
---------------------------------------------------

'Debug ip nat detail' is turned on and the ping test is repeated. No debug
output is produced. 'Sho ip nat trans' reveals a blank/empty translation
table.

I assume the ping arrives at the router based upon the policy experiment,
but I must be too much of a novice to understand why NAT does not occur in
the NAT experiment. It's using the same ACL as criteria; it just does not
make any sense to me. This is a 1720 router with IOS 12.2(4)T1.

"@NOSPAMhod!SPAM.co(dot)uk" <""tim\"@NOSPAMhod!SPAM.co(dot)uk"> wrote in
message news:f6d294$149b$1@energise.enta.net...

James · Guest

Maybe something to do with the ICMP type? When you ping a device you
send a type 8 message, but the device responds with a type 0 message.
Maybe an access-list something like this will work:-

ip access-list extended d115
permit icmp any host 6.22.8.115 echo
permit icmp host 6.22.8.115 any echo-reply
permit tcp any host 6.22.8.115 eq 80
permit tcp any host 6.22.8.115 eq 443

Unfortunately I don't have any spare hardware to test this with.

James

usenet · Guest

I've observed some consistent behavior that may explain this:

Using the following NAT technique (put forth in the original post) to
forward packets from public IP 6.22.8.115 to inside address 172.16.2.200:

ip access-list extended d115
permit icmp any host 6.22.8.115 echo
permit tcp any host 6.22.8.115 eq 80
permit tcp any host 6.22.8.115 eq 443

ip nat pool 200 172.16.2.200 172.16.2.200 netmask 255.255.255.0 type rotary
ip nat inside destination list d115 pool 200

All IP packets that arrive to the router 'unsolicited' will engage in the
standard order of operations (policy routing, nat, normal forwarding, etc)
with the *exception* of ICMP which will specifically bypass NAT in the order
of operations. As such, the first line in ACL d115 is completely moot; ICMP
8 packets arriving on the outside interface will not trigger NAT at all,
irrespective of ACL; the ACL will never even get checked against this
packet.

Alternatively, using this technique to forward the packets instead:

ip nat inside source static 172.16.2.200 6.22.8.115 ext

Will in fact forward ICMP packets destined for 6.22.8.115 to 172.16.2.200 as
expected.

The disadvantage to the static NAT method is the loss of extended ACL
criteria control. All data destined for 6.22.8.115 gets forwarded to
172.16.2.200, rather than the restricted set of ports permitted by ACL d115.

I believe this may have something to do with the fact that ICMP packets
don't really have ports. Within the context of inside destination
forwarding, it would appear that a static 1:1 mapping is required in order
to forward ICMP packets to an inside address. Using a many:1 rotary pool,
even if you put only 1 IP address in the pool, is still technically a many:1
style configuration which will cause the router to skip NATing of ICMP
packets in the order of operations (when they arrive on an outside
interface).

This is consistent so far with two different router models (a 1720 and a
2621) running different IOS versions. The behavior appears to be by design.

"usenet" <usenet@use.net> wrote in message
news:3wIii.25010$C96.9674@newssvr23.news.prodigy.net...

James · Guest

Interesting - I may dig out some routers and give this a try myself.

Any reason why you don't create an Inbound access-list to filter the
traffic or are you just experimenting with NAT in particular?

James