ip nat outside source problem

[dardanarusha]

This is the case:

NOC -- NAT Router -- Modems

NOC IP address: 192.168.29.1/24

NAT Router IP: FE0: 192.168.29.2/24 - NOC side

FE1: 172.16.0.1/20 - Modems side

Modems IP addresses: 172.16.0.0/20

We are forced to use FE0 as ip nat outside and FE1 as ip nat inside interface.

This is the configuration:

access-list 101 permit ip host 192.168.29.1 172.16.0.0 0.0.15.255

ip nat pool Modems 172.16.0.1 172.16.0.1 prefix-length 20

ip nat outside source list 101 pool Modems

While debug-ing we see that the packets get source NAT-ed from 192.168.29.1 to 172.16.0.1, but when those packets come back, they never get destination NAT-ed.

Any help would be appreciated,

Dardan

[shaferr]

Not sure which IOS you are running or which platform but try this link.

"http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a0080093f8e.shtml"

It looks like your pool is not configured properly. You have to allow the pool to assign a seperate address or use the overload command.

!

ip nat pool Modems 172.16.0.1 172.16.0.2 prefix-length 24

!

ip nat inside source list 101 pool Modems

!

access-list 101 permit 192.168.29.1 0.0.0.0

The link should help. You also might try searching NAT overload configurations. Hope this helps.

Rick

[dardanarusha]

This is our configuration now:

ip nat pool Modems 172.16.0.1 172.16.0.2 prefix-length 20

ip nat outside source list 101 pool Modems

access-list 101 permit ip host 192.168.29.2 172.16.0.0 0.0.15.255

This is the output of debug ip nat and debug ip icmp (we try to ping the host 172.16.0.2)

*Jan 13 21:36:05: NAT*: s=192.168.29.2->172.16.0.1, d=172.16.0.2 [23533]

*Jan 13 21:36:05: ICMP: echo reply rcvd, src 172.16.0.2, dst 172.16.0.1

*Jan 13 21:36:10: NAT*: s=192.168.29.2->172.16.0.1, d=172.16.0.2 [23571]

*Jan 13 21:36:10: ICMP: echo reply rcvd, src 172.16.0.2, dst 172.16.0.1

The output of show ip nat translations:

Pro Inside global Inside local Outside local Outside global

--- --- --- 172.16.0.1 192.168.29.2

icmp 172.16.0.2:512 172.16.0.2:512 172.16.0.1:512 192.168.29.2:512

On the link you posted it says:

When the packet is travels from inside to outside, the routing table is checked for the destination first, and then translation occurs.

Since the returning packet has the DA 172.16.0.1, is it possible that the destination NAT (from 172.16.0.1 to 192.168.29.2) never happens?

Although "ip nat outside source list:

- translates the source of the IP packets that are traveling outside to inside;

- translates the destination of the IP packets that are traveling inside to outside" tells us differently.

Thanks in advance,

Dardan

[Kevin Dorrell]

The debug ip icmp is telling you the dst address before translation back to 192.168.29.2. I suppose it depends where the command monitors, before or after the return NAT. Can anyone confirm this? I can never remember the processing order of the interface features.

OTOH, I don't see any output from the debug ip nat for the return packet. Maybe the reply is terminating on the router itself.

I would really like to see the full configuration. It sounds as if you may have configured 172.16.0.1 as an interface address on the router, as well as part of the NAT pool. If that is the case, then the router might believe that the response terminates on the router itself, rather than NAT it back to the 192.168.29.2 host. If this is the case, then you could exclude the interface address from the pool.

I'm not 100% clear about NAT, but I think there are two ways of configuring (if this is wrong, perhaps someone could educate me please):

1. You NAT from the single interface address by specifying the interface in the NAT command. The router then recognises the return packet as NAT, swaps the address, and forwards.

2. You NAT from a pool that should not include the interface address itself.

Kevin Dorrell

Luxembourg

Kevin Dorrell

Luxembourg

[dardanarusha]

This is our configuration:

interface FastEthernet0/0

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

duplex full

no cdp enable

!

interface FastEthernet0/0.1

encapsulation dot1Q 10 native

ip address 192.168.29.2 255.255.255.240

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip virtual-reassembly

no cdp enable

!

interface FastEthernet0/0.2

encapsulation dot1Q 4

ip address 192.168.254.137 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

no cdp enable

!

interface FastEthernet1/0

ip address 192.168.26.1 255.255.255.0 secondary

ip address 192.168.126.254 255.255.255.0 secondary

ip address 172.16.0.1 255.255.240.0 secondary

ip address 10.0.0.1 255.255.240.0

no ip unreachables

no ip proxy-arp

ip nat inside

ip virtual-reassembly

no ip route-cache cef

no ip route-cache

no ip mroute-cache

duplex full

no cdp enable

!

ip classless

no ip http server

no ip http secure-server

!

ip nat pool InternetModems 172.16.0.1 172.16.0.1 prefix-length 20

ip nat outside source list 101 pool InternetModems << although we have added overload, it doesn't appear on the config

!

!

access-list 101 deny ip host 192.168.29.1 host 172.16.0.1

access-list 101 permit ip host 192.168.29.1 172.16.0.0 0.0.15.255

access-list 102 permit ip host 192.168.29.1 192.168.126.0 0.0.0.255

The platform is Cisco 7206VXR, IOS version c7200-jk9o3s-mz.123-8.T3.bin. We have tried this with other IOS, without success.

The output of the debug ip icmp is:

*Jan 14 00:49:22: ICMP: echo reply sent, src 172.16.0.2, dst 172.16.0.1

*Jan 14 00:49:22: ICMP: echo reply rcvd, src 172.16.0.2, dst 172.16.0.1

1. When you use ip source outside you can not configure the interface in the NAT command.

2. I'm not quite sure how can we do this, since the packet should come back to that interface.

Thanks very much in advance,

Dardan

[pravinpednekar]

There is no difference in this. To clarify further there is Destnation NATting happening here.

i.e for eaxmple

- translates the source of the IP packets that are traveling outside to inside;

NATS source of IP packet from outside to inside communication is Destination IP from people sitting inside

e.g : yahoo -> your inside IP

here yahoo woulde get natted

translates the destination of the IP packets that are traveling inside to outside"

ge - your inside ip -> Yahoo

here again yhaoo ip would be natted

Hope this clarifies your doubts

Regards

Pravin Pednekar

[dardanarusha]

Apsolutely agree, but, as you can see on my next post, it just doesn't happen.

Appreciate your help,

Dardan

[shaferr]

In response to Kevins post see the following link:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

I agree that when the outbound packet is translated to the same ip as the outbound interface when the reply is returned it stops at the interface. Your debug ip nat seems to be showing what it should but the destination is the interface. I also think in order to use the overload command you must use the interface in your source list command not the ip address. Not sure on this but that is how I have always done it. You have a current IOS so I dont think it is a feature problem unless that feature set doesnt support NAT overload. Try taking the interface address out of your pool and see if that works.

See the above link for the order of NAT operations.

Hope this helps.

Rick

[Kevin Dorrell]

Rick,

Thanks for the doc. It gives me a good checklist of the processing order. Unfortunately there was one interesting feature missing in the list - ip packet debug. Perhaps I should send them a comment asking them to add it at the appropriate point.

Kevin Dorrell

Luxembourg

[dardanarusha]

Rick,

did you mean something like this:

ip nat pool Modems 172.16.0.2 172.16.15.253 netmask 255.255.240.0

ip nat outside source list 101 pool Modems

Sorry to say, still doesn't work.

Results of debug ip nat:

*Jan 15 03:59:51: NAT*: s=192.168.29.2->172.16.0.2, d=172.16.0.3 [52079]

*Jan 15 03:59:51: ICMP: echo reply rcvd, src 172.16.0.3, dst 172.16.0.2

Note: the host now has the IP address 172.16.0.3. It was reporting IP conflict when it had it 172.16.0.2.

What do you think about a workaround, somekind of policy routing or redirection?

We implement this kind of NAT in Linux very easily:

iptables -t nat -A POSTROUTING -s 192.168.29.2 -d 172.27.0.0/20 -j SNAT --to 172.27.0.12 (where 172.27.0.12 is the IP address of the interface).

BTW what is ip nat create flow-entries? Is it for Net-flow? Could not find any docs on cisco.com.

Thanks in advance,

Dardan

[shaferr]

Could you give us a little more background on your scenario and what you are trying to accomplish. There may be a better way to get where you want to go but Im not sure exactly where that is with the information we have. As for the Net Flow command I havent worked with that one but Ill see if I can find anything.

Rick

[shaferr]

A few other quick notes as I was looking at this again. Try your ping using the extended commands and specifically sourcing it from the 192.168.29.x address. Im thinking that it is possible that the source address is not what you think if you are pinging from a console or telnet session. Have you tried turning proxy arp on?? Just a few more ideas.

Hope this helps.

Rick

[dardanarusha]

We want to be able to ping and snmp query the modems behind the router. The modems don't have routes. The only way would be if we source NAT the packets so they go to the modems with the source IP address from the same subnet.

We tried with te ip proxy-arp but had no success.

I hate to see the Linux guys laugh at my Cisco,

Dardan

[frenzeus]

When u tried ip proxy-arp, did u try having change your noc to the 172.16.0.0 range of ip address? Try putting in a secondary ip address with range of 172.16.0.0/28 under Int Fa0/0.1, which is not used by any of your modems. It should do a proxy arp for your noc.

If u use nat, i dont think it'll work as your overload address is the ip address of int fa1/0. When int fa1/0 receives the icmp reply from your modems to destination address of 172.16.0.1/28 (supposedly intended for your noc), i guess int fa1/0 is indeed the destination address and does not further nat it back to 192.168.29.1. Even if u try using another ip address to perform overloading, with the same ip address in the same subnet as 172.16.0.0/28, there's no reason for the packets to cross a layer 3 device right, since they're all in the same subnet

I may be wrong, but i'm looking at it in a logical sense.

[dardanarusha]

Thanks a lot guys. Finaly it worked. Here is the configuration:

interface FastEthernet0/0.1

encapsulation dot1Q 10 native

ip address 172.16.0.1 255.255.255.248 secondary

ip address 192.168.29.2 255.255.255.240

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip virtual-reassembly

no cdp enable

!

interface FastEthernet0/0.2

encapsulation dot1Q 4

ip address 192.168.126.254 255.255.255.252 secondary

ip address 192.168.254.137 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip virtual-reassembly

no cdp enable

!

interface FastEthernet1/0

ip address 192.168.26.1 255.255.255.0 secondary

ip address 10.0.0.1 255.255.240.0

no ip redirects

no ip unreachables

ip nat inside

ip virtual-reassembly

duplex full

no cdp enable

!

ip classless

ip route 172.16.0.0 255.255.240.0 FastEthernet1/0

ip route 192.168.126.0 255.255.255.0 FastEthernet1/0

no ip http server

no ip http secure-server

!

ip nat pool InternetModems 172.16.0.2 172.16.0.2 netmask 255.255.240.0

ip nat pool DTSModems 192.168.126.253 192.168.126.253 netmask 255.255.255.0

ip nat outside source list 101 pool InternetModems

ip nat outside source list 102 pool DTSModems

!

access-list 101 permit ip host 192.168.29.2 172.16.0.0 0.0.15.255

access-list 102 permit ip host 192.168.254.138 192.168.126.0 0.0.0.255

We'll be doing some more test and come up with the config that suites our scenario the best.

Thanks a lot,

Dardan