nat problem

Presumably you mean 10.200.210.240.

Out a physical interface other than Ethernet0?

Wouldn't your return traffic be:

access-list 110 permit ip 172.20.2.0 0.0.0.255 10.200.210.240 0.0.0.0

If the ping was sourced from a host 192.168.254.x, and the router has a connected route to 192.168.254.0, why would you need to specify a next-hop on 192.168.254.0? Why would you need a route-map on Loopback0?

Best Regards, News Reader

News Reader a écrit :

No, i only have one interface (eth 0), that's why i set up a loopback interface for nat

yes, but the access-list 110 is for the route map to 192.168.254.6

because only the packets sourced from 10.200.210.240 have to be routed to 192.168.254.6 (even if i have the default route to 192.168.254.6, it won't be the final gateway)

News Reader a écrit :

As it's only a test for the moment, i removed the route-map on loopback, et keep the default route to 192.168.254.6.

it's not working better... it worked the same way.

Are there any ACLs on L0 or E0 that are not shown in the output below?

Best Regards, News Reader

News Reader a écrit :

this is the new config (without routing after nat)

---- begin ---- ! interface Loopback0 ip address 10.200.210.240 255.255.255.0 ip nat outside ! interface Ethernet0 ip address 192.168.254.4 255.255.255.0 ip nat inside ip policy route-map NatSource ! ip nat inside source list 101 interface Loopback0 overload ip classless ip route 0.0.0.0 0.0.0.0 192.168.254.6 ! logging trap debugging logging facility local0 logging 192.168.254.7 access-list 101 permit ip 192.168.254.0 0.0.0.255 172.20.2.0 0.0.0.255 access-list 110 permit ip 10.200.210.0 0.0.0.255 172.20.2.0 0.0.0.255 route-map NatSource permit 10 match ip address 101 set ip next-hop 10.200.210.1 !

---- end ----

don't work better, as i said.. :(

I leaved the acl 110 : it's no more used, it should not be a problem..

The pinging host (192.168.254.110) is using E0 (192.168.254.4) as its default gateway, right?

Can I assume there is no other NAT being performed (e.g.: on 172.20.2.0)?

Have you examined the NAT translations (sh ip nat translations) to confirm that they are what you expect?

Have you placed a sniffer on the network to verify the IP addresses within the packets on both the outbound and return paths? Seeing is believing.

Best Regards, News Reader

News Reader a écrit :

Not the default gateway, there's a route for this destination (172.20.2).

no other nat. :)

Yes, it seems to be ok : Pro Inside global Inside local Outside local Outside global icmp 10.200.210.240:1280 192.168.254.110:1280 172.20.2.75:1280

172.20.2.75:1280

result for just one ping :

10:34:52.609141 IP 192.168.254.110 > 172.20.2.75: icmp 40: echo request seq 31750 10:34:52.609202 IP 192.168.254.110 > 172.20.2.75: icmp 40: echo request seq 31750 10:34:52.616734 IP 10.200.210.240 > 172.20.2.75: icmp 40: echo request seq 31750 10:34:52.672776 IP 172.20.2.75 > 10.200.210.240: icmp 40: echo reply seq 31750 10:34:52.672879 IP 172.20.2.75 > 10.200.210.240: icmp 40: echo reply seq 31750

nothing else..

thank you for your interest :)

92.168.254.4) as its

debug nat

or is it debug ip nat

shows all of the packets. Quite handy.

Think you mis-understood my question.

When the host (192.168.254.110) is sending a ping to a destination (172.20.2.75) for which it does not have a route, it uses "it's" default gateway. I was wanting to confirm that the host's default gateway was configured as 192.168.254.4, to ensure that packets were using the router on which your NAT and route-map were configured.

Your NAT translation output below answers the question.

Just one ping? Where is this trace taken from?

Why are you seeing multiple requests/replies with the "same IP addresses and same seq number"?

Would expect each request to a have a unique seq number; at least from a Windows host.

Might want to examine the MAC addresses of each packet.

Best Regards, News Reader

News Reader a écrit :

no. really. :) on 192.168.254.110, there's a route to 172.20.2.0 with 192.168.254.4 gateway. the default gateway is set to another router..

192.168.254.110 host.

I don't know.. this is a windump trace (equivalent to tcpdump under linux)

I made a new trace with wireshark (still for just one ping, and from

192.168.254.110): 1 10:31:28.635270 192.168.254.110 172.20.2.75 ICMP Echo (ping) request Destination: Cisco_f2:65:d8 (00:30:80:f2:65:d8) Source: Intel_62:c1:2d (00:07:e9:62:c1:2d) 2 10:31:28.635330 192.168.254.110 172.20.2.75 ICMP Echo (ping) request Destination: Cisco_f2:65:d8 (00:30:80:f2:65:d8) Source: Intel_62:c1:2d (00:07:e9:62:c1:2d) 3 10:31:28.641375 10.200.210.240 172.20.2.75 ICMP Echo (ping) request Destination: Cisco_7f:b0:a6 (00:0c:85:7f:b0:a6) Source: Cisco_f2:65:d8 (00:30:80:f2:65:d8) 4 10:31:28.696839 172.20.2.75 10.200.210.240 ICMP Echo (ping) reply Destination: Cisco_f2:65:d8 (00:30:80:f2:65:d8) Source: Cisco_7f:b0:a6 (00:0c:85:7f:b0:a6)

00:30:80:f2:65:d8 is 192.168.254.4 router

00:0c:85:7f:b0:a6 is 192.168.254.6 router 00:07:e9:62:c1:2d is 192.168.254.110 host

the whole capture can be read from

I dont understand why there are two same echo request at the begining ?

snipped-for-privacy@hotmail.co.uk a écrit :

I tried, but it didn't give really infos more interesting.. thank you anyway.. :)

Yes, you stated this and it didn't sink in, sorry.

If you wanted, you could create a file called "ethers" and place it in the Wireshark program directory so that packets in the trace identify the hosts at the MAC level.

file content e.g.:

00:30:80:f2:65:d8 router-a 00:0c:85:7f:b0:a6 router-b 00:07:e9:62:c1:2d host-1

If that's the whole trace, then the packet is being dropped before or after NAT. I took a look at the NAT Order of Operations document again as a refresher (NAT outside-to-inside, Policy Routing, Routing) and don't see an issue.

Your initial post stated 'translation isn't working when the ip packets are comming back".

Bod43's advice on using "debug ip nat" is good.

You'd look for something like this: Apr 17 12:03:25.019 EDT: NAT*: s=172.20.2.75, d=10.200.210.240->192.168.254.110 [IP packet ID]

... to confirm NAT function on the return path.

If the router is quiet enough to tolerate it, you might try following debug to see if you can draw any conclusions about the forwarding of the ping reply to the host:

router # debug ip packet detail

If you were using inspection you might benefit from:

ip inspect log drop-pkt ip inspect audit-trail

... although I don't know that they would convey "cause".

When you stated "just one ping" I took it literally (i.e.: following a single ping packet vs. multiple packets generated by a single ping command).

I have not used NAT on the same physical interface as you are here, and have not had to address this issue. I too would like to know the answer.

Best Regards, News Reader

I stopped searching. :) I resolved my problem using a linux box and iptables, instead of a cisco box ;) I would have like to know the answer, but i don't have enough time, so..

Thank you for your interest and patience :)