IP Masquerading Concepts Under LINUX 2.2

Using IP Masquerading Every Day

Masquerading is great when it works and can be miserable to troubleshoot when it doesn't. Things can go wrong if you've specified rules that masquerade too much, not enough, or in the wrong direction. It may also be that the protocol doesn't lend itself to masquerading and is not supported via a protocol module. But in my experience, bad rules are often to blame.

First, think about what you want to accomplish. For a dial-up connection into another corporation, you probably want to masquerade everything headed from your network into theirs so that it can be returned back to you. The easiest way to do that is to masquerade everything that's leaving that interface. Something like ipchains output -I -j MASQ -i ppp0 seems like it would do the trick. The rule means that everything that leaves the system over interface ppp0 is masqueraded, regardless of its source or destination. Unfortunately, that won't work, because the -j MASQ target is valid only for rules on the forward chain. If you use the same format with a forwarding rule (without specifying a source or a destination), you'll be masquerading in both directions—or will you? And should you be masquerading in both directions anyway? (This might be okay, but before you jump on it you need to determine whether you want traffic coming back into your network from the PPP link to appear to originate from your extranet router.)

Instead of waxing philosophical about how to provide rules, I believe that they're easiest to understand by looking at pictures of what works and what doesn't. Masquerading is a topic with a lot of subtleties, and for me it was sometimes easier to grow accustomed to how to use it than to understand all the details of how it worked. Throughout this section, the router is shown to have two Ethernet devices, eth0 and eth1. That both of these are Ethernet devices is purely arbitrary. The concepts are valid if either of the interfaces are replaced by an interface of another type. The convention in the drawings is that eth0 is on the inside and eth1 is on the outside, when such a distinction is applicable.

Secret #1 The Linux kernel is smart about what to masquerade. When you have a rule that instructs the kernel to masquerade packets matching a particular source network/mask, it chooses the IP address to place in the headers, depending on which interface is used to forward the packet. As an example, see Figure 3.

Figure 3

Masquerading interface is chosen based on packet destination.

Instead of replacing the packet's source IP with any IP on the system, it always uses the IP of the interface over which the packet will be sent.⁵ This is the same interface that appears in the routing table for either the gateway route or network route that must be used to reach the destination IP. If you think about it, this is exactly what you want to happen. Any other action would be nonsensical, because the packet wouldn't be routed back to you over the same interface, if at all.

Secret #2 Masquerading is directional with respect to client-server transactions. A client/server transaction refers to the paradigm in which the client initiates the connection to the server, sends to the server, and the server responds. As Figure 4 shows, we can represent such a connection as a pair of arrows, first from client to server and then from server to client. The router in this picture is configured to masquerade any packets with a source address in subnet_A. The masquerading bends the arrows a bit (because of the port changes), but the connection precedes correctly.

Figure 4

Masquerading is directional—inside out.

It should come as little surprise that if the packet source address doesn't match, the packet is not masqueraded. What about the reply? It has a source address from subnet_B, not from subnet_A. However, the reply is unmasqueraded correctly because the kernel is expecting it and because it arrives on a special port.

What's interesting is when a client on subnet_B tries to open a connection to a server on subnet_A, as depicted in Figure 5. (For this example, let's assume that the host on subnet_B has a valid route to subnet_A, which won't always be the case.)

Figure 5

Masquerading is directional—outside in.

The packet passes from client to server untouched by the router because the source address did not match any of the packet criteria for masquerading. The server on subnet_A formulates a response to the client and sends it. But now the packet matches the masquerading code. The kernel knows that something is amiss, since this isn't the direction implied by the arguments given when establishing the rule, and it throws the packet into the bit bucket. Figure 6 shows another aspect of this situation.

Figure 6

Masquerading is directional.

You can verify this independently using packet sniffers—the server on subnetA will respond, but the response never gets forwarded by the router. One of the reasons to mention this case is that not all masquerading routers are positioned between only two networks. If you use source-based rules without explicitly defining forwarding rules for the nets that should be able to communicate unmasqueraded, you may experience problems. This can be further compounded by the fact that ICMP (for example, ping) and UDP (for example, traceroute), which use both, will traverse this configuration in both directions without a problem. This can be alleviated by using interface-based masquerading rules, but you should know that they also have an implied direction and nuances.

Secret #3 Masquerading for an interface occurs only when the interface specified is the forwarding interface. Figure 7 depicts a configuration in which masquerading is set up to be performed on the eth1 interface, which I'll call the outside. The interface on the inside is eth0.

Figure 7

Interface masquerading must occur on the forwarding interface.

As shown by the arrows in Figure 7, connections from the inside out are masqueraded, but those from the outside in are not. To complete our terminology, the forwarding interface is the interface on the router that sends (forwards) the outbound (inside out) connection. The packets that emerge from this interface will be masqueraded, provided that they met any other criteria in the masquerading rule (such as protocol, source, or destination addresses). For an inbound connection, eth1 is the receiving interface, not the forwarding interface.

In addition to the definition of the forwarding interface, the situation is identical to the source-based masquerading example with respect to direction. Client-to-server connections that are forwarded by the masquerading interface will succeed. Client-to-server connections that use the masquerading interface as a receiving interface for packets in the client server direction will be swallowed by the kernel.

So what do the secrets mean? That depends on your masquerading application. Perhaps they might save you some time when configuring masquerading on your system. Packet sniffing is an excellent way to troubleshoot masquerading problems, but you need to monitor both sides of the masquerading router to get the complete picture of what's happening. The following list shows some other things to keep in mind when troubleshooting masqueraded connections, so that you don't spend all day chasing ghosts:

• The problem may not be with your rules configuration, but may be because you have failed to load the correct module to masquerade the protocol being used.

• The protocol you're using might not have masquerading support in the kernel at all. Watch out for protocols where the server tries to open a connection with the client.

• When dealing with extranet connections, sometimes the problem is either the NAT or some firewalling on the remote side (although masquerading a masqueraded connection does work when correctly configured).

• Firewalling rules and masquerading rules are executed sequentially, in the order defined by your configuration. Take care that you're not filtering out part of the masqueraded connection (perhaps by blocking part of the masquerading port range).

• Proxies are an excellent way of avoiding the issue for Internet masquerading. One drawback is that you may have to give up some of the standard services you run on that system—for example, Telnet—or train your users to Telnet to a different port when connecting to a client. However, not everything can be proxied (in which case you need either masquerading or NAT).

• There are tools available to aid you in configuring masquerading—sweet, nourishing tools! (See the earlier section "IP Masquerading Configuration Tools.")

Why Masquerade?

This article introduces IP masquerading in conjunction with the configuration of a dial-out server/router for a technical support team that needed to access client systems. It was used to overcome a technical snag in connecting two corporate networks. Whether the IP addresses were private or not wasn't always the issue; it was often a question of coordination with the other network administrator. Neither of us wanted to exchange network information, worry about address space collisions, or expend efforts in reconfiguring our networks for an infrequent (although important) application. In short, the router uses IP masquerading because of its convenience.

The most common motivation for the use of IP masquerading, however, is for Internet access from clients on private subnets. If your organization is using any of the private subnets listed in RFC 1918, you'll be required to either provide proxy servers or perform masquerading for these clients to access the Internet. Even if you can get Internet-routable address space, you may choose to use private address space. After all, it's nice to have all that address space at your disposal when planning your network. For both of these reasons, you'll often see IP masquerading discussed side by side with packet-filtering firewalls and proxies as part of discussions for using it on an Internet gateway. But aside from allowing access from machines where access wouldn't normally be possible, you may find yourself using IP masquerading for applications in which the traffic could have been routed normally. In essence, you're obscuring the identity of the sender from the receiver, which has a couple of tangential benefits, as described in the following sections: First, it's a security measure. Second, it can be used to condense traffic.

IP Masquerading as a Security Measure

Say that a user on your network is using a Web browser to access a less-than-reputable Web site. Web browsers have loose tongues and almost always reveal the operating system of the sender. Should someone on the receiving side have unscrupulous ideas with regard to users of this particular operating system, he or she may launch an attack against the sender. In the case of masquerading, the attacker won't have access to the IP of the true sender. Instead, he or she will launch an attack against the wrong system. Although perhaps not the most quieting of examples, it is the Right Thing to limit attacks against users.

IP Masquerading to Condense Traffic

Although this application is less frequent, sometimes you may not want to know the IP address(es) of those who are contacting you, even if routing isn't a problem. In this case, you're purposefully masquerading incoming traffic before it enters your network. One reason may be because your servers are having a hard time performing (reverse) name lookups on the IP address coming over the link, resulting in long DNS timeouts for client connects. Another reason may be for logging purposes, when you want all connections from a certain site or IP range to appear to originate from a single point. If you wanted to get an idea of the amount of Web traffic the group on the second floor generated on the proxy server, you could configure IP masquerading from that router interface to the HTTP proxy server at port 80. This might not be your modus operandi, but you could configure it for a day just to generate statistics. A third reason would be to bypass a problem in your network. (Refer to Figure 8 as part of the following scenario.)

Figure 8

Rerouting traffic with IP masquerading.

When everything works, each site routes over its link directly to the other site. Now imagine that the link_BC goes down in the middle of B's night. C is in the office and unhappy about not being able to access B, and A is on the phone and unhappy about being the only WAN admin available for comment. Here's one solution:

1. Log in to C's router and reroute traffic toward A over link_AC.

2. Configure router_A to masquerade all traffic originating from C and bound for B.

3. B's servers will see traffic from router_A and respond to it, avoiding link_BC. Make sure that you have the protocol modules loaded on router_A so that things like FTP will work.

4. Send an email to the users at C that not everything is going to work wonderfully in this scenario, but most services (anything that can be masqueraded) will.

5. Go back to bed, but make sure that you get the password for router_B for future reference.

By nature of its incredible usefulness—and therefore popularity—there are many resources available to assist you in configuring IP masquerading. A quick search on almost any Web search engine should produce hundreds of hits (in at least a dozen languages), so you shouldn't have any problem locating resources. If you do, try the Linux Documentation Project.