xchg eax, eax

Networking | 2010-11-03 11:47:25

What happens if you want to communicate with a network that you don’t have a route for? In a normal situation you would just install a new route across the network, either statically or via a dynamic protocol like EIGRP or OSPF.

However what do you do if this isn’t an option? I had this problem the other day because the remote network was owned by another company and we didn’t want to request for routes to be installed or to run a routing protocol. However there was a mutual network that could access both ends. We decided to run up a NAT scenario, however for end to end communication to be successful we need to NAT both the source and destination addresses in each packet.
The diagram below should show things a bit better. In our situation we had Call Manager servers we needed to access, but the 10.10 network couldn’t hit the 10.20 network. So we NATted up on the 10.15 network.

Here’s how we achieved the NATting.

ip nat pool VOICE1 10.15.0.1 10.15.0.1 netmask 255.255.255.0
ip nat inside source list NAT_ACL_VOICE1 pool VOICE1 overload
ip nat pool VOICE2 10.15.0.2 10.15.0.2 netmask 255.255.255.0
ip nat inside source list NAT_ACL_VOICE2 pool VOICE2 overload
ip nat pool VOICE3 10.15.0.3 10.15.0.3 netmask 255.255.255.0
ip nat inside source list NAT_ACL_VOICE3 pool VOICE3 overload
ip nat outside source static 10.20.0.1 10.15.0.1
ip nat outside source static 10.20.0.2 10.15.0.2
ip nat outside source static 10.20.0.3 10.15.0.3
ip route 10.15.0.1 255.255.255.255 10.20.0.1
ip route 10.15.0.2 255.255.255.255 10.20.0.2
ip route 10.15.0.3 255.255.255.255 10.20.0.3
ip access-list extended NAT_ACL_VOICE1
remark PERMIT LOCAL NETWORK
permit ip 10.10.0.0 0.0.0.255 host 10.15.0.1
deny ip any any
ip access-list extended NAT_ACL_VOICE2
remark PERMIT LOCAL NETWORK
permit ip 10.10.0.0 0.0.0.255 host 10.15.0.2
deny ip any any
ip access-list extended NAT_ACL_VOICE3
remark PERMIT LOCAL NETWORK
permit ip 10.10.0.0 0.0.0.255 host 10.15.0.3
deny ip any any

A quick run down on how I *think* it’s working, correct me if I’m wrong.

To change the source addressing information we create a NAT pool with one valid IP (our NATted IP). To filter this from NATting all traffic we apply a NAT ACL onto the pool and overload it (PAT).
To change the destination addressing information we create an outside static NAT.
Because of the way outside NATting works, it will route the packet before NATting it. Eventually one of our routes will match the remote network but this won’t apply the NAT properly. To get around this we force a longest match route, which will always match and NAT properly.

Finally we just need to activate our interfaces for NATting.

int fa0/1
ip nat inside
int fa0/0
ip nat outside

This may not be the cleanest way to do this (and it’s pretty tedious making a new pool for every address you need) and I may have got the actual details about what is happening where not 100%, but this example is running in production now on one of my networks without any dramas.