I have a specific requirement to NAT some legacy wireless devices that are accessing a mainframe application using hardcoded IP addresses. The mainframe is moving to a new site, and we cannot touch each of the legacy devices to either do name resolution or change the destination IP.
All wireles devices tunnel to the WLC which is installed in a Cat6504 with Sup2T. The IP NAT Inside will be on one of the wireless WLANs that maps to a Catalyst VLAN.
The 6504 attaches via Layer 3 to two core 6509 switches. I expect to put IP NAT outside on each of these Layer 3 uplinks.
I'm concerned about traffic that may flow non-symmetrically up one uplink and back via the other.
Would this break the NAT?
How are the 2 core switches interconnected ?
My initial response was to say use a NAT pool because i don't think NAT keeps track of the interface in the translation table so i would have thought it would work. Obviously you would need to advertise the NAT pool to the core switches.
But depending on how the 2 core 6500s are interconnected would a simpler solution be to just use NAT overload on the L3 IPs on the 6504. That way the traffic should always route back to the correct interface. That is assuming that the core switches are exchanging routes and see the shortest path to the other 6504 L3 interface via the other core switch, if you see what i mean.
Jon, this is a destination NAT, not a source NAT. The wireless devices are hardcoded to access a mainframe app at 10.1.86.201. I need them to go to 10.31.86.201.
Okay, so you would have something like -
ip nat outside source static 10.31.86.201. 10.1.86.201
and the wireless vlan would be "ip nat inside" and the 2 L3 interfaces would have "ip nat outside" .
I can't test this but a static NAT does a full translation ie. it record src IP/src port and dst IP/dst port. Because of this i think when the packet goes out from the inside a full translation is created so the return packet would simply use that translation whichever interface it came in on.
But what i said in my previous post still applies unless you cannot NAT the source IPs because you want to record the IPs or it breaks the application. You could still overload the source IPs so that they are always returned to the correct interface on the 6504.
If NAT overload isn't an option then you could use NAT pools to translate the source IPs but it could get complicated in terms of routing ie.
1) you have a NAT pool per L3 interface on the 6504.
2) each NAT pool is advertised to it's respective core 6500 but you would need to make sure that the NAT pool was always routed back to the correct core switch. This may involve manipulating metrics and/or filtering routes between devices.
3) you then can use route maps with the NAT that not only match the source IP but also the outgoing interface so it picks the right NAT pool to use.
That though, as you can see, is quite complicated. And the biggest problem as i say is to control the routing from the core switches so that if the return packet hits the wrong core switch it is routed across the interconnect (assuming there is one) to the right core switch before being sent back to the 6504.
So with one of the above you should be able to get it to work . You have the "ip nat outside source static ..." command and then for the client IPs either don't NAT (which i still think might work), overload the source IPs so it goes back to the right L3 inetrface or use NAT pools for the src IPs together with route maps.
Note that both solutions where you NAT the source IPs depends on the core switches always routing the return traffic to the correct L3 interface so they must not see the preferred path to one L3 interface on the 6504 via the other L3 interface.
Sorry i cannot be more specific in terms of what will work but i just don't have anything to test with at the moment.