Network Architecture 101

Firewalls don't always need to be implemented in routers, nor must they be hardware-based. Several software routers exist that can play the same role as a hardware solution. For example, Check Point Software Technologies offers the well-known Firewall-1 product, and Microsoft provides RRAS for Windows Server 2003 and Windows 2000 Server. Many of these software-based solutions also provide an integrated VPN server that can host VPN connections between your external users and your internal network. In general, the decision to use a hardware- or software-based firewall or routing solution will depend on cost (software solutions are usually less expensive than hardware solutions for similar functionality) and performance (hardware-based solutions typically have greater throughput than software-based solutions).

Another feature often found in routers or other firewall devices is Network Address Translation (NAT). NAT is used when internal network hosts with private, non-Internet-routable IP addresses need to talk to Internet-based hosts with public IP addresses. I'll talk more about private IP addressing in the next section, but NAT servers provide a valuable service and are found in many network-perimeter devices on the market today. You'll likely need some device on your network perimeter to perform this NAT function. Often, an application proxy can provide this functionality.

Application Proxies
Application proxies—or more simply— proxies, are common in enterprise networks. Proxies are generally software solutions (but can be hardware solutions) that provide a sort of bucket brigade of communication between hosts on the internal and external network. The most common type of application proxy is the HTTP proxy (aka Web proxy), but you can use proxies for many different types of application traffic, including FTP, Telnet, remote procedure call (RPC)-based applications, and even Internet Control Message Protocol (ICMP—Ping). Many of you are probably familiar with the Web proxy because you must enter that pesky proxy server address in Microsoft Internet Explorer (IE) whenever you want to browse the Internet from your work network. The Microsoft Internet Security and Acceleration (ISA) Server add-on to Windows Server is an example of a common software-based application proxy.

Proxies act as intermediaries between your internal and external networks: Requests from the internal network to the external network are shunted to the proxy. For example, if I browse to http://www.microsoft.com from my internal network, the page request actually goes to the proxy server. The proxy server terminates the request, then sends a new request on my behalf to the target Web site. Thus, no direct connection exists between my internal network and the Internet: The proxy server is the go-between. When the destination Web site responds, the proxy again takes that response and forwards it back to my Web browser on the original connection that I initiated. As well as providing additional security to a network, a proxy is a convenient place for logging what's going on between the internal network and the Internet, so if an employee is browsing an illicit Web site, you can easily go through the proxy's logs to determine who visited the site and when. Because application proxies require access to both the internal and external networks, they're usually located on the DMZ or equivalent segment within your network topology. Now let's move inside the network and talk about some best practices for deploying switches, routers, server farms, and workstation segments.

The Internal Network
The first thing you need to determine when building your internal network is which IP addressing scheme to use. Most organizations use a private IP address namespace rather than public IP addresses. This approach originated because public IP address space is limited. As the Internet grew and this limitation became problematic, private IP addressing mitigated the problem. Another reason private addressing has grown in popularity is because it gives organizations the flexibility to widen their IP network without fear of having to change or carve up their IP address space as they grow. Private IP addressing follows an organized Internet standard, defined in the Internet Engineering Task Force (IETF) Request for Comments 1918 (RFC 1918), which you can view at http://www.isi.edu/in-notes/rfc1918.txt. RFC 1918 defines the following three address blocks, one for each IP address class (A, B, and C), as private:

(IP address class A) 10.0.0.0 - 
	10.255.255.255
(IP address class B) 172.16.0.0 - 
	172.31.255.255
(IP address class C) 192.168.0.0 - 
	192.168.255.255

For more information about IP address classes, see "IP Addressing Basics," September 1999, InstantDoc ID 7035. You can use any of these IP address blocks to segment your internal network. Of course, using one or more of these address blocks internally means that you must have a NAT device at the perimeter of your network that can translate these nonpublic addresses into addresses that can be routed publicly; that's usually the job of a router, proxy, or multifunction edge device.

Your choice of which private address block to use is generally a function of your network's size. Large networks with many devices and many routed segments generally use the Class A 10.x address space, but a Class B address might be sufficient for smaller organizations. Much depends on how you segment your internal network. When routers first appeared on the scene in the 1980s, it was common to have many routed segments or broadcast domains within a corporate network. (A broadcast domain is so called because broadcast-based traffic—traffic intended for all devices—is bound by a router interface, as Figure 3 shows. Routers typically don't forward broadcast traffic.) Back then, Ethernet was a common Layer 2 protocol, as it remains today, but the majority of Ethernet devices were connected by shared hubs. Because the performance of Ethernet degrades significantly when too many devices are on one shared broadcast domain, the typical network workaround was to create many small routed segments.

   Previous  1  [2]  3  4  Next