NetFilter NAT | Policy Routing Using Linux

NetFilter NAT

As you explored in Chapter 6, the packet filtering structure within the Linux 2.4 series kernel is NetFilter. Because you had used the fwmark interface (called nfmark in NetFilter) to tag packets, you noted that there were structures that existed to allow for NAT within the NetFilter architecture. To determine how these structures function within the Policy Routing arena, you perform a series of tests within your test network setup.

First you do some research into the style of the NetFilter structure as it pertains to the NAT function. In contrast to the bidirectional routing NAT style, NetFilter treats the direction of the NAT as an element of the NAT function. This granularity provides an additional construct that can provide for unidirectional NAT.

The two types of NAT as defined by NetFilter are the Source NAT (SNAT) and the Destination NAT (DNAT). SNAT maps outbound packets as they leave the system, hence the name Source NAT rightly implying that the source address changes. DNAT maps inbound packets as they enter the system, hence the name Destination NAT rightly implying that the destination address changes. These mappings may be applied using any of the NetFilter packet selection mechanisms, thus providing a level of granularity in the packet selection mechanisms.

After studying the NetFilter command structures, you first decide to try to rework your One-to-One NAT setup using the facilities provided by the NetFilter architecture. To this end you ensure that the iptable_nat module is loaded (see the NetFilter documentation for details), and then you set up the same One-to-One NAT using the original single address model. You end up with the following series of commands:

  iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.1/32 \   -j SNAT --to 10.1.1.253   iptables -t nat -A PREROUTING -i eth1 -d 10.1.1.253/32 \   -j DNAT --to 192.168.1.1

Upon issuing any IP connection from address 192.168.1.1 to host2 you find no connection is completed. Inspecting the packet trace from Network B you see that the packets leave router1 with the NAT addressing correctly changed, but that host2 does not know how to respond and ARPs repeatedly for the 10.1.1.253 address. This is unlike the situation in FastNAT where router1, the default router for host2 in both cases, received the packet and applied the translation without needing to own the address. But you find that NetFilter requires router1 to own the address 10.1.1.253. Upon adding in the command ip addr add 10.1.1.253/32 dev eth1 and running ip route flu cache , you see the NAT working correctly.

Now you know how to do a simple One-to-One mapping in NetFilter. You then try to set up the extended One-to-One NAT mapping such as you had done with the routing NAT function earlier. So you try the following set of commands:

  iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.32/27 \   -j SNAT --to 10.1.1.64-10.1.1.95   iptables -t nat -A PREROUTING -i eth1 -d 10.1.1.64/27 \   -j DNAT --to 192.168.1.32-192.168.1.63

When you start testing from the 192.168.1.32 address, you notice on the packet dumps from Network B that the source addresses are incrementing upwards for every packet you send. So your first packet through from 192.168.1.32 has a source translation of 10.1.1.64, the second packet is 10.1.1.65, and so on. Not even close to the behavior of the FastNAT. Then when you look at the verbose output of the NetFilter information, using iptables -t nat -L -n -v , you see that the DNAT setup has no packets using the rule at all. Just out of curiosity , you delete the DNAT rule and note that the opera tion of the system is unchanged. You finally deduce that to do One-to-One ranged NAT with NetFilter you must specify each NAT transaction independently.

For most of the cases where you would be making use of these structures you would use fairly static defined mappings anyway. The additional setup would not be a big deal unless you were doing wholesale NAT translations of complete IP address spaces, and in that case you could use the FastNAT construct.

You note that in the case where you specify this command sequence using only a single address on the one side and a range of addresses on the other, you have a clear example of One-to-Many NAT. This type of NAT structure is not very interesting for you but you can see some simple load balancing uses for it, such as multiple internal Web servers.

One of the security structures that does interest you is the use of the Many-to-One NAT. In Linux this was traditionally called IP Masquerade, and you would like to implement it for some sequences of addresses. To this end you first try a quick test to masquerade all output to Network B as router1, 10.1.1.254. You implement the following commands:

  iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 10.1.1.254

The packet traces from Network B show that all traffic from net1 to either host1 or host2 has a source address of 10.1.1.254. Now you know that the SNAT worked due to router1 owning the 10.1.1.254 address. This makes you wonder what constitutes ownership. From your solid understanding of the Address Triad element you suspect that any assignment of the appropriate address to the system would work. To prove your conviction you delete the preceding SNAT rule and try the following sequence:

  ip addr add 172.16.13.13/32 dev dummy0   ip link set dev dummy0 up   iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 172.16.13.13

And, voila, the output from router1 into Network B has source address 172.16.13.13. Finally, to ensure that you are truly into twisted setups you add the following command:

  iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 172.16.13.13

You can now see that the source address for packets on both Networks A and B is 172.16.13.13.

But there is a catch that makes you pause. You notice that the SNAT only takes place when the origination of the initial connection is from the affected network. In other words, you only see the source translation on packets that are not responses. To illustrate , you look at the sequence where you send packets from net1, 192.168.1.32 address, to host2, 10.1.1.3. The packet traces from Network B show the source translated to 172.16.13.13. But the packet traces from Network A do not show the responses from host2, 10.1.1.3, translated as you would expect from the dual SNAT. When testing from host2 to net1 you find the contrapositive sequence.

This is a function of the connection tracking mechanism within NetFilter. The connection tracking is what negated the DNAT in the test of One-to-One NAT and also in the testing of extended NAT. The connection tracking mechanism performs exactly as you would expect from the name. However, this is also the feature that negates the status of NetFilter NAT as a routing function and relegates it to a packet mangling function performed solely on a single system.

Consider that you have a triple connection setup as in Figure 8.1. You would like to implement an asymmetric, or loopy, routing structure. In this structure, traffic destined for the corporate Web server will enter only through the ISP#1 connection. When it enters it will be NATed to an address in CA. The response then returns to the Internet through ISP#2 with the same original destination address from ISP#1. Under NetFilter there are time-outs and connection tracking overhead associated with the SNAT and DNAT features. Each time a packet comes in through Router1 there is a connection track set up for the eventual "return" of the response. Similarly, each time a packet leaves through Router2 there is a connection track set up. These connection tracks take time to timeout. There is also a finite number of such connections that may be tracked due to memory and processing power on the system.

Top