Policy Routing NAT
Policy Routing NAT
Since NAT is a routing function, you decide you want to try out some of the various uses. You decide to return to the test setup you had in Chapter 6. This scenario is shown in Figure 8.2 as a refresher.
Figure 8.2. Test network schematic.
You are now going to use router1 to do some testing. To this end you set up the testing environment as follows :
NetworkA 192.168.1.0/24 NetworkB 10.1.1.0/24 net1 192.168.1.1/24 router1 A 192.168.1.254/24 router1 B 10.1.1.254/24 host1 10.1.1.2/24 host2 10.1.1.3/24
Since you have the capability of looking at the actual packet traces, you decide to try a simple NAT in which all packets from net1 to host2 are NATed by router1 to 10.1.1.253. The ip utility allows you to perform a one-to-one NAT mapping, which is called FastNAT in the kernel documentation. You decide to try out the FastNAT setup with ip . The command sequence you determine for the ip utility is as follows:
ip route add nat 10.1.1.253/32 via 192.168.1.1 ip rule add from 192.168.1.1/32 nat 10.1.1.253 prio 15000
Now from net1 when you ping, telnet, or use any other IP transport-based protocol to get to host2, you see on the packet dump that the source address has been changed to 10.1.1.253. Indeed, if you use net1 to go to any of the 10.1.1.x addresses you see that the source is changed.
This is a complete One-to-One NAT between these two addresses. If you use a packet generator or protocol that embeds the original address within the data section of the packet, you see that the only address changed is the header source. The embedded address does not change. This is the main reason certain protocols, such as IPSec and SNA/IP, cannot be NATed due to their embedding the original source address within the data part of the packet. Since this is an extreme security risk on the Internet because of internal address leakage, you usually will not want to route such protocols across the Internet, but rather either encapsulate them or tunnel them. In the case of IPSec and related security protocols, the best solution is to always use legal IP addresses.
Curious as to the extent of the routing NAT structure, you decide to see if you can perform an extended NAT mapping. You want to see if you can do a group One-to-One NAT from the address space 192.168.1.32/27 to 10.1.1.32/27 and see if the changes are mapped One-to-One. So you add the following rules:
# On net1 i=32 while [ $i -lt 64 ]; do ip addr add 192.168.1.$i/32 dev eth0 i=$((i+=1)) done # On router1 ip rule add from 192.168.1.32/27 nat 10.1.1.32 prio 14000 ip route add nat 10.1.1.32/27 via 192.168.1.32
From the packet traces on Network B you can see that the mapping is correctly One-to-One across the range. If you use the 192.168.1.37 source you get the translated address of 10.1.1.37. Just to make sure you change the 10.1.1.32/27 range to 10.1.1.96/27. You see that when you use the 192.168.1.37 address it gets translated to 10.1.1.101 just as a One-to-One mapping would demand.
This result allows you to have a ranged NAT defined on all of your border routers. Recalling Figure 8.1, you could define several sets of addresses within each of the three Corporate sites and have all three border routers contain complete range NAT maps for these subnets. As an even weirder stretch you note that with a single NIC policy router you could translate local network addresses for machines without multiple address capabilities.
If you recall the setup you implemented in Example 6.3 from Chapter 6 where you implemented asymmetric routing, you see that you can now have a distributed Policy Router set up that provides all of these services plus NAT. Consider implementing Example 6.3 on a system such as Figure 8.1. Assume for a moment that your company does not own its own address block but instead depends on addressing from each of the three ISPs. Your contracts with each of the three ISPs allow outbound traffic that is addressed from any of the three, but will not route inbound except to their own address blocks. This is a fairly standard multi-ISP setup in corporate environments. Are you then limited to one ISP address block for your external Web server?
No. Consider that you have control over your corporate DNS. You can specify multiple addresses for your Web server in the DNS, say one address from each ISP. Set up a single common Web server with three addresses. Each border router now has an inbound NAT mapping for the local ISP address that is DNS-coded for the Web server, and three outbound NAT mappings for each of the three addresses. If you track the local routing structure on your border routers, the outbound packets from the Web server can be routed by whatever border router is closest to the destination and will receive the correct outbound address that was used to query the server. In this case you get effective failover for the Web server as seen by the outside world. If any of the ISPs is down, you still have Web services available.
Note
The scenario mentioned above where one ISP allows you to route outwards through their network the set of IP addresses you obtained from a different ISP was a common practice in 1994 “1996. With the advent of many of the IP Spoofing attacks and Denial-Of-Service (DoS) attacks, this output of addresses became a suspect activity. RFC-2267 (January 1998) urges ISPs to implement filtering to prevent IP addresses other than the ones that the ISP themselves own out from the ISP's network. This is often implemented as an ingress filter on the ISP's internal network, hence the referral to Ingress. While this mitigates some menial forms of IP Spoofing, it does not control the notorious DDoS (Distributed Denial of Service) attacks. These are DoS attacks that are launched from a collection of "zombie" machines by a single controlling administrator. Thus the recent dramatic increase in use of DDoS engines. Indeed, the increasing implementation of RFC-2267 is also driving the use of NAT as a method of maintaining a multi-ISP spanning Internet connection. Adding more extensive use of NAT to the ubiquity of DDoS slave engines being installed is a very frightening scenario. But the willingness of ISPs to at least start implementing some control mechanisms is a very promising move. Hopefully, the greater addressing space structures and formalities of routing IPv6 will help every multi-connected company obtain and manage its own legal IP address space, which will moot all of this discussion.
Of course in many of these cases there are security consequences for which you must allow. And the interactions between the security structures and the NAT structures can get very hairy. When you consider them both under the umbrella of the global routing structure, it is easier to see what points of contention will arise. Since you do run packet filtering and stateful inspection firewall systems, you turn your attention to the interactions that exist between these types of systems and your routing NAT structures.
| Top |
