Routing failure with NAT

[kmcdonnell]

We have 10.x.x.x internal addressing scheme. Third party companies connect via NAT router, dmz and firewall. Some third party companies also use 10.x.x.x addressing. For these we use NAT and translate the source 10.x.x.x to 192.168.x.x. We have /32 static routes on our NAT router to various 10.x.x.x addresses and forward to the firewall. We also have routes to the various 192.168.x.x NAT'ed address of the third parties and send to the outside interface they connect to.

This all worked well until we decided not to have individual static routes in the NAT router for various internal addresses and put in 10.0.0.0 255.0.0.0 next hop firewall in the belief that we would send all 10.x.x.x destined packets to the firewall.

What appeared to happen is packets from outside had source address translated correctly and passed to the firewall, return packets ( Inside to Outside) should have went to the router engine first and seen a route for the NAT'ed 192.x.x.x address and then the packet should have been sent to the NAT engine for translation back to the original 10.x.x.x source address. I think this happened but then the router engine took over again and instead of sending the packet to the outside interface tried to send the packet to the inside interface courtesy of the new route we put in.

If we go back to /32 routes for specific internal 10.x.x.x addresses it works OK again.

[thisisshanky]

Have you enabled ip classless, while doing so ??

[kmcdonnell]

ip classless is enabled

[thisisshanky]

Does any of the outside 10.x.x.x addresses, overlap with the inside network addresses, if that is the case, you cannot use a single supernet (10.0.0.0/8) static route ,pointing to the firewall. Previously, it used to work with individualy /32 routes, because, router was using longest match rule for packet forwarding, and henceforth, routing with NAT was working fine. Check to see if you find any overlap in addresses, between inside and outside network addresses.

[kmcdonnell]

Why should this be an issue as for Inside to outside traffic routing table is looked up first and finds the route to 192.168.x.x address as the destination, the packet should then go to the NAT table and get translated back to 10.x.x.x and then forwarded to the outside interface without any further route table lookups. This works I know because we have other third party customers eg their original source address is 150.100.x.x that we translate to 192.168.x.x and we don't have a route entry for the 150.100.x.x network just the NAT'ed entry.

Also we never removed the /32 static routes jsut added the /8 route so the longest match rule was used anyway for the valid internal routes.

[kmcdonnell]

Is there any further thought on this issue? Is this a bug or is the route table actually looked at again after the NAT and if there are no routes is the packet forwarded to the outside interface?

Thanks

Kevin

[anup.anand]

Since you are doing NAT on incoming traffic from outside, the inside interface for NAT should be the one which connects to the outside world, and the outside interface for NAT should be the one that connects to your local network. Hence the return packets are acutally going from the outside NAT interface to the inside NAT interface. The normal way NAT works is for traffic from Outside to Inside, packets will be NAT-ed first then Routed. After NAT-ing, it gets the 10.X.X.X address and then it will be routed using the new 10.0.0.0/8 route that you added now. Also are you having a default route ?? if yes, then before it was using that default route to go to the outside interface.

[thisisshanky]

Hello Kevin,

For further analysis, can you paste your relevant configs. I wanted to know which inteface you have configured as inside NAT interface and which you have configured as outside NAT interface. I assume your wan interface is your Inside NAT, as packets coming from 10.x.x.x networks of your customers are being NATed to 192.168.x.x network.

Also note that when packets come back from your local network, destination address of those packets would be 192.168.x.x. and when it reaches router, NAT is done first and 192.168.x.x is remapped to 10.x.x.x network (of your customer) and then routed to the customer. So you really dont need a route to 192.168.x.x network on your router. You have mentioned in your post that,

"We also have routes to the various 192.168.x.x NAT'ed address of the third parties and send to the outside interface they connect to. " which is not really needed, as NAT is done first and then routing is done, provided, you have configured your wan interface as outside, and ethernet (local network) as outside.

So for further analysis, it would be easier, if you could paste your configs.

[kmcdonnell]

Below is a sample of the configs we have on the router. The basic premise is we don't want to see 10.x.x.x source addresses on the DMZ side of the firewall.

We translate these to 192.168.5.x for this customer. The customer also doesn't want to route out to 10.x.x.x addresses so we provide a translated 192.168.3.x address for them to route across the WAN to.

***This interface is connected to the DMZ and all traffic passes to our internal network via a firewall.

interface FastEthernet0/0

description DMZ - FrameRelay Router

ip address 192.168.0.9 255.255.255.0

ip nat inside

*** This interface connects to one of our customers

interface Serial0/1.200 point-to-point

bandwidth 512

ip address 192.168.62.33 255.255.255.252

ip nat outside

*** Here we NAT a particular inside address to another for the customer to connect to.

ip nat inside source static 10.1.1.1 192.168.3.41

*** Here we NAT the customers source address so don't see 10.x.x.x on the outside of the firewall***

ip nat outside source static 10.1.11.253 192.168.5.253

****The internal address routed via the firewall

ip route 10.1.1.1 255.255.255.255 192.168.0.43

****The customers NAted address routed via the Serial

ip route 192.168.5.0 255.255.255.0 192.168.62.34

Customers source address 192.168.5.253 (destination for return packets from the firewall) gets

NATed back to 10.1.11.253 before going out the serial interface.