Figure 2.5 illustrates the high-level architecture of the firewall. In particular, it shows the possible paths that can be taken by a packet received on an interface (solid lines), and the possible paths of response packets, if any (dashed lines). The dotted lines indicate authentication exchanges to validate the request for service.
In the diagram, a packet is received on network 1. It is seen by the packet sniffer/injector, which decides whether the packet should be gatewayed by the transparent gateway program or whether it should be handled by one of the servers or proxies running on the firewall.
If the packet is sent to the transparent gateway, the gateway checks whether the packet `belongs' to an already established session, or whether a session should be created for it. If neither of these is the case, the packet is dropped. Otherwise, any necessary network address translation (NAT) is done to the packet, along with any necessary header and payload modification, and the modified packet is then injected into the second network.
In general, a session will only be created if the packet is received on the internal network interface, the only exceptions being Archie, TFTP or FTP server callbacks (in which case the gateway must be expecting these to allow them), and non-NATed NetBIOS (which is allowed but discouraged).
Network address translation is performed by the gateway as follows:
The external server sees the request as though it came from the firewall, and sends the response to the firewall. The firewall uses knowledge of the prior requests to determine which internal client the response should be sent to, and sends the response on. When the client receives the response, it appears to be from the external server. The `transparency' is thus only in the view from the inside; from the outside the entire internal network is hidden, with only the firewall itself visible.
From this, it is easy to see how the decision about whether a packet should be handled by the transparent gateway is made. If the packet comes from an internal host and is addressed to an external host, then it should be handled by the gateway. In the other direction, packets received on the external network (which are all addressed to the firewall) should be gatewayed only if they belong to previously established sessions.
Packets from the inside addressed to the firewall, or new client requests from the outside, are not handled by the transparent gateway. Instead, they are passed through a set of packet filters to ensure that no vulnerable services running on the firewall are accessible, and then handled by an appropriate proxy or server if appropriate. Unlike the transparent gateways, proxy connections are explicit two-step connections - a host connects to the firewall, and then the firewall connects to the destination host on the other side. A proxy application on the firewall then relays data between these two separate connections. The end result is very similar, but proxies have the disadvantage that setting up the initial connections is more complex.
Whether a connection is made via a proxy or via the gateway, your internal host addresses are not visible to the external network and thus need not be legitimate Internet addresses. Hosts on the external network only see the firewall; they are unaware of the fact that connections are actually coming from a network residing behind the firewall, and do not see the internal addresses. This means you can deploy the firewall as your gateway to the Internet without having to change your internal addresses at all. The only registered Internet address you need is for the external network interface on the firewall (and also for your router , unless you are using a synchronous card, or PPP or SLIP to connect to the external network). This is a particularly useful feature for organisations with `legacy' IP addresses, where there are many hosts with IP addresses that are not registered Internet addresses.
However, if your network is already connected to the Internet and uses legitimate Internet IP addresses, then you need to change these addresses, or use an additional network address block for the network between the external interface of the firewall and the router . You can reduce the number of changes required by subnetting one of your existing networks to free up addresses for use by the firewall.
An implication of address hiding is that the transparent gateway cannot be used to gateway connections from outside to inside: there is no way an external host could (or should) know the addresses of or routes to your internal hosts. Access to services from outside to inside is always via the proxies, if it is allowed at all (the exception once again being non-NATed NetBIOS gateways). Deciding whether a connection is allowed or not is the subject of the next section.
A further implication is that you cannot connect to an Internet host which has the same address as one of your internal hosts. Usually this is not a serious problem, and it may be easier to live with the restriction than to change all of your internal network addresses. However, if you are prepared to change the addresses of your hosts, you should use addresses from the following ranges:
| Range | Comment |
| 10.0.0.0 ...10.255.255.255 | One class A network |
| 172.16.0.0 ...172.31.255.255 | 16 class B networks |
| 192.168.0.0 ...192.168.255.255 | 255 class C networks |
These addresses are official non-Internet addresses (defined by RFC1918); you can be guaranteed that there are no hosts directly accessible from the Internet which use them.
![\includegraphics[width=14cm]{citsys.ps}](img14.png)