Partly-dynamic / partly-static NAT

[jmkelly]

For historical reasons, we have to NAT just one of our networks on its way to a colo. Our network is 10.0.0.0/9, the colo's is 10.240.0.0/22, and most of our networks can go through untranslated--but another customer is using 10.1.0.0/22, so we have to translate that one: our 10.1.x.y <=> 10.2.x.y, with x and y remaining constant.
I set that up a couple of weeks ago and it works fine. HOWEVER, when a server at the colo tries to access a printer on our 10.1.0.0/22, it uses the NATted address (as it should), and that address comes right through the "outside" interface and never gets translated.
The problem is, basically, that the only way a translation gets added to the NAT table is when a packet from 10.1.0.0/22 enters the "inside" interface bound for 10.240.0.0/22. I need that to keep happening, but I also need packets from 10.240.0.0/22 entering the "outside" interface to have their destination addresses translated from 10.2.x.y to 10.1.x.y, and again x and y must stay the same.
The only way I see to get this done is to add static NATs for the dozen or two printer addresses, but I really hate to do that--it's ugly and cumbersome. Anyone see another way?

 

[brianinms]

In your case your only option would be Static Nat. However, the bigger question is why isn't your network segmented at the colo? Each client of a colo should be in a separate VRF in which there would be no IP overlap and no nat necessary.

 

[jmkelly]

Brianinms, thanks for the reply. Cisco Tech Support concurs. An interesting difference between the Cisco ASA and its IOS routers: the ASA had no trouble with this, the router....
As to your bigger question, the answer may be that we're passing through an MPLS cloud and the provider is willing to provide only so many layers of VRF. I know that another parallel situation we have, all the clients' traffic is NATted on the way to the colo. The NATting is done on the provider's edge routers.
Anyway, thanks for the help.