Although there may be a few AS/400 shops left where twinaxial cable and green-screens rule, most offices are now wired for a network. If your shop was an early adopter of the technology, you probably had a Token-Ring network and used NetBEUI or IPX/SPX for the network protocol. Whether your Token-Ring network is still in use or you've installed an Ethernet, chances are that TCP/IP is now running the show. Used by virtually all vendors, TCP/IP is the language of the Internet. In its bid to make the AS/400 a player on the 'net, IBM has imbued it with a comprehensive TCP/IP suite. Although the early incarnations of TCP/IP on the AS/400 were lousy performers, each succeeding release of the AS/400 operating system, OS/400, has seen improvements in both performance and features. In this article, I'll examine a couple of the gems nestled in the features list of recent releases of TCP/IP on OS/400. Specifically, this article will cover the Network Address Translation (NAT) and IP filtering functions.

Some Dry Theory: A TCP/IP Primer

Before carving into the meat of the topic, I'll first look at some of the basics of TCP/IP. Because a comprehensive discussion of TCP/IP is well beyond the scope of this article, I'll limit the discussion to an extremely simplified overview and concentrate on topics germane to NAT and IP filtering. If you're already a networking guru, you are welcome to skip to the next section.

Although development is currently underway for a new-and-improved TCP/IP (IP V6), IP addresses in the current version (IP V4) are composed of 32 bits. To make it easier

for mere humans to work with these addresses, they are typically broken down into four eight-bit pieces, separated by decimal points, providing numbers from 0.0.0.0 through
255.255.255.255.

IP addresses are further broken down into two parts: the network address and the node address. Networks are grouped by class based upon how much of the address is given to the network address and how much to the node portion. The 0 in each of the examples represents the node address. Class A networks are defined using the first octet
(x.0.0.0), where x can have a value of 1 through 127 inclusive. There aren't many class A addresses available, so only the biggest users can acquire a class A network address. Class B networks use the first two octets for their definition (x.y.0.0), where x has a value between 128 and 191. Class C networks, which are what most users deal with, use the

first three octets (x.y.z.0) and start with an x value between 192 and 223. The node addresses 0 and 255 are reserved; the former represents an entire network, and the latter represents a broadcast address for an entire network. In contrast to class A network addresses, many more class C network addresses are available; however, each can have only 254 nodes. (Remember that 0 and 255 are reserved.) In addition, some of the address ranges are reserved. For example, the 127.x.x.x series has been reserved for a "loopback" device, which can be used for testing on computers without Internet connections.

In a perfect world, there would be enough IP addresses available so that every computer (for that matter, any networkable device, such as any of the new pervasive computing devices [e.g., Palm Pilots or cell phones]) could have its own unique address. It doesn't take much "figgerin'" to see that, with only 32 bits available for addressing, the pool of addresses dries up rather quickly. (I'll discuss the workaround for this problem in this article.)

Assume for the moment that you have two computers that are connected by a simple Ethernet hub. The first computer is an FTP and HTTP (Web) server. The second is a simple workstation that will be a client to the first. For these computers to talk to one another via TCP/IP, they must have the same network address and each must have a unique node address. In the case of a class C network, this means that the first three octets must match but the fourth octet must be unique. Assuming everything is connected and configured properly, the question then becomes, "How does the server know which service the client is requesting when a connection request is made?" The answer is simple: logical ports. Within each TCP/IP packet are embedded not only the source and target IP addresses (the sender and receiver) but also a from-port and to-port number. TCP/IP has provisions for 65,536 logical ports. Logical ports under 1,024 are known as well-known ports because the function of each has been defined in the IP specifications. In the case of the first computer, the FTP server normally would be listening on port 21 (the FTP port), and the HTTP server normally would be listening on port 80. These ports are not carved in stone. In fact, on many systems you can make adjustments to one or more of your server configurations to change the port on which the server listens for a connection. http://www.yourdomain.com would become http://www.yourdomain.com:2000 when you attempt to connect to your server.

One additional piece of information attached to each data packet is important to this discussion: the protocol type. There are three main types of IP communications protocols. The first is the Internet Control Message Protocol (ICMP). ICMP is used mainly for error reporting between machines. Utilities such as PING use ICMP to determine connectivity between machines.

The second type is the User Datagram Packet (UDP). UDP is rather simplistic, as it does not provide reliable end-to-end communications. The sender of a UDP has no guarantee that it was received on the far end. UDP is used for Domain Name System (DNS), Simple Mail Transfer Protocol (SMTP), and tasks like streaming audio and video. (Its unreliability suggests that it's also the type of communication used by many parents and their teenaged children.)

Unlike UDP, TCP is a connection-oriented protocol that establishes a connection between two hosts. TCP will always ensure that the packet is received at the far end; if the packet was not received, TCP will retransmit it until it is. Telnet, FTP, and HTTP are all examples in which TCP is used.

These three pieces of information-source/destination IP address, source/destination port, and protocol type-are the basis for NAT and IP filtering.

Going to the (Masquerade) Ball

As I mentioned, there's a problem (actually more than one) with IP V4: IP addresses are in limited supply. To circumvent the problem, addresses have been reserved for private networks. Figure 1 provides a list of these addresses, which are considered "nonroutable."

Actually, they are nonroutable by agreement. ISPs will not route packets containing these addresses onto the Internet. Networking equipment within your organization, however, will happily route the packets throughout your private network.

So, if you assigned private addresses to your private network when you set it up, you now have a problem. How do you access computers on the Internet from computers on your intranet? Here is where the Network Address Translation function comes into play. If you refer to Figure 2, you'll see an example of how NAT works. In this example, the internal network is using private class C network addresses. The computer that will do the address translation has two interfaces. One interface is connected to the internal network and has IP address 192.168.1.1. The other interface has an address that has been assigned by the company's ISP, which, in this case, is 201.10.15.75. Packets that are outbound from the internal network are modified so that the source IP information (address and port) contained within them now has the IP address of the public interface-again, 201.10.15.75. As far as the computer on the public network is concerned, the packet was sent from the NAT computer. When it responds, the NAT computer will determine which computer within the private network requested the packet, rewrite the packet with the appropriate internal address information and check sums, and then place the packet onto the internal network. These transactions are transparent to both the private and public computers.

NAT has some additional benefits. Separating your internal network from the outside world hides the internal configuration of your network from prying eyes. Because packets with private addresses won't pass to the outside world, you gain a certain measure of security right away. Of course, you won't want to rely on that as your only security measure.

There is no doubt that some of you completely ignored the use of private IP addresses when you originally set up your network. After all, you were never going to put your network on the Internet, and I, uh, I mean you were in such a hurry to get your network going that you simply pulled an IP address out of the air and started configuring. With NAT, you can avoid the nasty accusation of being an IP thief and put off reconfiguring your internal network until a later date. But the fact remains that you still need to either use NAT or go back and reconfigure your internal network to use a unique IP addressing scheme. Why? What if your company merges with another and you have to join your network to the associated networks of the new company? NAT can be a godsend in this case, as you'll probably be dealing with two completely different network addresses. Even worse, maybe both networks are using the addresses from the same private network address and now you have to join the two. NAT can be just the ticket for avoiding the IP address collision you'll likely encounter.

NAT Flavors

NAT actually comes in four flavors known as: static, round-robin, masquerading, and dynamic. The first two, static and round-robin, are of concern when you're dealing with inbound connections to your private network. The latter two are of interest when you're dealing with outbound connections. The AS/400 currently supports static and masquerading NAT. The others are available in dedicated networking products.

Static NAT is probably the easiest to understand. Inbound packets for a given public address will be mapped to a specific internal private address. There is a one-to-one mapping of public addresses to private addresses. You'll need to specify the mapping during configuration.

Round-robin works very much like static NAT, but it maps a single public address to a pool of internal addresses. The purpose is to provide a means of load balancing across a number of servers-for instance, if you had multiple HTTP servers servicing the same public IP address. As with static NAT, you'll have to provide the private addresses to be included in the pool.

Masquerading is probably the most interesting for the small business that doesn't currently have a full-time Internet presence but needs a cheap connection for email and Web surfing. In this scheme, many internal addresses are mapped to one public address. If the external interface is a dial-up connection to an ISP, then all of the internal computers can use the connection simultaneously. Assuming that no one is downloading huge files over this connection while others are surfing, the response time should be adequate for most uses.

Dynamic NAT is similar to masquerading, but there is a pool of public addresses available. The number of simultaneous connections from the inside to the outside is equal to the number of public addresses. Each is maintained in a one-to-one correspondence, just as in static NAT. The difference is in the direction the connection is to be initiated-from the inside to the outside.

The Traffic Cop

With NAT, it's a fairly simple process to interconnect two IP networks. By itself, NAT will route packets from one network to another, even if that's not exactly what you'd like to happen. To restrict the traffic that crosses between the networks, you'll want to do IP filtering. IP filtering is almost always discussed in the same breath as NAT. Combined with NAT and routing, IP filtering can make a fairly useful firewall.

The concept of IP filtering is rather straightforward. An outgoing packet arrives at your gateway machine (the one doing routing and NAT), where it is inspected and compared with a list of rules. When a matching rule is found, the packet is dropped or processed by NAT and forwarded to the outside, depending upon what your rule defines for the disposition of the packet. Inbound packets go through the same process, except that NAT is applied first and then the packet is filtered and, if permitted, routed to your internal network.

The criteria available for filtering packets is quite extensive. You can filter packets by direction so that the rule you specify applies in one or both directions. You can filter by source or destination address, essentially limiting external access to your network to specific hosts or networks as well as limiting outgoing connections to specific hosts (thus precluding visits to porn sites). You can filter by source or destination port, selectively permitting or denying access to specific services in either destination. You can also apply your rules to specific physical interfaces, such as Ethernet or Point-to-Point Protocol (PPP), the dial-up interface. The protocol can be used as a filter criteria so you can allow TCP but deny UDP, should the need arise. Just remember that, when you're designing your rules, the safest approach is to deny everything by default and then add specific rules that conform to your requirements.

For more on IP filtering, check out "Secure Your AS/400 with IP Filtering" in the August 2000 issue of MC.

Even the Birds and the Bees Do It

So what does it take to set up NAT? Most server operating systems, such as OS/400, Linux, the UNIX variants, Windows NT Server, and Windows 2000 Server are capable of NAT and IP filtering. To access NAT on your AS/400, fire up the Operations Navigator (OpsNav) and double-click on the AS/400 systems icon then the system icon for your AS/400. Double-click on the Networks icon, then protocols and finally right-click the TCP/IP icon and select "IP Packet Security." This will bring up the menu shown in Figure
3. NAT is controlled in the section marked "Address Translation." Whether or not utilizing NAT is a good use of rather pricey CPU cycles is a topic for discussion, but it's good to know that you can.

Being the Linux fan that I am, I feel compelled to put in a plug for Linux in handling the duties of NAT. I've used Linux's NAT/IP filtering capabilities many times for

simple masquerading and firewall duties with great success. It also presents a great opportunity to use your older 486 CPUs!

IPv6 will eventually supercede IPv4 and many of the problems currently solved by functions such as NAT and IP Filtering will be solved permanently (www.6bone.net/misc/ case-for-ipv6.html), rendering the functions obsolete. Linux kernel 2.2 currently has IPv6 support (www.bieringer.de/linux/IPv6) so it's ready for the future. Hopefully, IBM will get that support into OS/400 in a more timely fashion than it did in getting a relatively complete IPv4 suite.

REFERENCES AND RELATED MATERIALS

• "Secure Your AS/400 with IP Filtering," Shannon O'Donnell, MC, August 2000
• V4 TCP/IP for AS/400: More Cool Things Than Ever, Redbook (SG24-5190)

Private IP Addresses From Address To Address Class Comments
10.0.0.0 10.255.255.255 A There is only one private class A network address.
172.16.0.0 172.31.255.255 B This provides for 16 different class B network addresses.
192.168.0.0 192.168.255.255 C This provides for 255 class C network addresses.

Figure 1: With IP addresses are in limited supply, some have been reserved for private networks.

Receives packet from
201.10.15.75

192.168.1.2

sends packet to blocked site
192.168.1.4

Sends packet to
204.65.59.111

.2

.3

.4

Figure 2: Use NAT to access computers on the Internet from computers on your intranet.

204.65.59.111

Internal Network

External Network

Request from.2 rejected

IP Filtering

NAT

192.168.1.1

Internet 201.10.15.75

Figure 3: You can control NAT and IP filtering via an OpsNav interface.

Also Read

Practical OSS: MkDocs for the IBM i, Part 2

Practical OSS: MkDocs for the IBM i, Part 1

Practical OSS: MMAIL from EASY400