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?
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
'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" wrote in message news:f6d294$149b$ snipped-for-privacy@energise.enta.net...
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.
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.
I'm iind of playing/learning, but I do have a task to accomplish. I did try using an inbound ACL at first, but the router also provides internet access to the LAN (by masquerading them as 6.22.8.115) which ends up generating a lot of inbound 'response' packets to 6.22.8.115 (on a bunch of arbitrary ports, which in this case I want to allow in). So that got kind of messy. I didn't know how to tell the difference between a lagit response packet bound for 6.22.8.115 and totally unsolicited traffic for 6.22.8.115.
NAT's inherent request/response nature seemed like it would do the heavy lifting for me here. So rather than filter inbound packets, I created an ACL to control what gets outbound NATed by the LAN in the first place. And without any public addresses assigned on the LAN, a packet must either be a response that matches something in the NAT table, or, be a packet that matches ACL "d115" (which will NAT to 172.16.2.200) if it wants to reach a host on the LAN (a poor man's firewall I suppose).
As I posted before, this ACL, when used in an inside dest list / pool nat, was consistantly ignoring icmp echo destined for 6.22.8.115
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
NAT will not use this inside dest rule on an icmp packet; but the icmp packet is still "up for grabs" to be NATed by a "static" rule. So,
ip access-list extended icmp115 permit icmp host 172.16.2.200 any
ip nat inside source static 172.16.2.200 6.22.8.115 rote-map icmp115 extendable
route-map icmp115 permit 10 match ip address icmp115 set interface FastEthernet0/1
I added the above static destination nat rule (that uses a route-map as an excuse to implement an ACL) to create a static (and conditioinal) icmp-only NAT between 6.22.8.115 and 172.16.2.200. Now when an unsolicted icmp packet arrives to the router it doesn't use the dynamic/d115 nat, but rather goes through the static nat. An unsolicted tcp:80 packet goes through the dynamic/d115 nat. Both packets end up at 172.16.2.200. Short of statically NATing *all* packets between 172.16.2.200 and 6.22.8.115, I couldn't come up with any other way to 'have my cake and ping it too'.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.