Hiding Network Objects

Because of the incredible and unpredictable speed at which the Internet has expanded, acquiring IP addresses for your organization has become more difficult over time. As a result, it has become increasingly important to use wisely the address space that is available. This is mostly due to the fact that there is very little unassigned public IP address spaced left and obtaining public addresses can be a very difficult and costly process. Ultimately, ICANN defines how addresses are allocated, but they delegate this responsibility to regional registrars who allocate addresses to Internet Service Providers (ISPs), who in turn delegate these addresses to companies. End-users can also request addresses directly from the regional registrar by following a process similar to what ISPs must do. In most cases, an end- user must be able to show 25 percent utilization immediately and 50 percent utilization by the end of the first year in order to receive public addresses directly from the regional registrar.

Using hide-mode NAT is one easy way to conserve address space while not limiting the functionality of your network. Hide-mode NAT enables you to hide an entire range of reserved address space behind one or more routable IP addresses.

The advantages of hiding network objects extend beyond simply conserving address space: hidden objects are not directly accessible from external hosts , and are therefore far less susceptible to attacks or unauthorized access attempts. Even though hidden objects benefit from this protection, you may still grant them full access to the Internet. FW-1 will translate packets originating from your hidden objects so that once their traffic leaves your firewall, they appear to be originating from a routable address. In turn, when the external host responds, the incoming packets are again translated by the firewall back to the original reserved address, allowing your hidden object to receive the response without knowing any translation took place.Because FW-1 translates source port as well as destination port, it is able to determine which internal host should receive an incoming connection, even if there are multiple connections destined for the firewall s external address. The firewall maintains a translation table, and from the source port in this table, it is able to direct incoming connections appropriately.

The following example will demonstrate how this process works, and how you can configure FW-1 to accomplish hide-mode NAT. One of the most common uses of hide-mode NAT, and where you will want to consider using it, is connecting your office workstations to the Internet. In order to accomplish this, you should assign your office workstations reserved IP addresses; we will use 172.17.3.0/24 for this example. This means that your workstations will use 172.17.3.1 as their default gateway, and you will configure this address on one of your firewall s internal interfaces. Then, each of your workstations will be assigned an address in the range of 172.17.3.2 to 172.17.3.254 (either manually or with a DHCP server).

One important issue to keep in mind is that your firewall must be licensed for sufficient hosts to encompass your DHCP scope, plus any statically assigned addresses. If you end up using more addresses than your FW-1 license contains, you will see repeated error messages in the system log on your firewall.

Now your workstations will be able to communicate with the internal interface of the firewall. Be sure to enable IP forwarding on your firewall; otherwise , packets will not be forwarded from one interface to another, and your workstations will not be able to gain connectivity from your internal network to the Internet, for example.

The next step is to look at the Address Translation tab in the Check Point SmartDashboard, as shown in Figure 5.1.

Figure 5.1: Address Translation Tab

The rules in this tab can be generated automatically, as we will discuss later in this chapter, or manually. In this case, we are going to add a manual rule to take care of hiding your office network. First, add a new rule by selecting Rules Add Rule Top from the menu bar. This will insert a blank rule at the top of the current rule base.

The address translation rule base has two main sections:

• Original packet

• Translated packet

When a connection comes through the firewall, it compares the packet for a match with the source, destination, and service of the original packet section. If a match is made, the firewall then alters the source, destination, and service as specified in the translated packet section.

Just as in the standard rule base, rules in the translation rule base are processed in the order that they appear ”top down, one at a time. This means that you have to be careful about where you insert new rules so that they are not overridden by rules that appear higher in the list. It is also recommended, for performance reasons, that you keep the most used NAT rules at the top of the NAT rulebase. This is discussed in more detail in Chapter 8.

Before you can configure the new rule you have created, you need to be clear on which network objects are involved. The first object you need is one representing your internal office network (172.17.3.0/24). This will be called Net_172.17.3.0. The second object required is one representing the routable IP address that you are going to hide the office network behind. In this case, you are going to hide the internal network behind the external IP address of the firewall, so it is not necessary to create a separate object for this ”you will use the existing firewall object called ExternalFW. Note that you can hide a network behind other addresses besides that of the firewall s external interface. To do this, you would simply create another network object representing this address. However, you may have to deal with some routing issues that are discussed below.

Now that we know which objects we are going to use, it is time to create the NAT rule. To do this, start with the Original Packet section of the new rule you created. Add Net_172.17.3.0 to the Source column, which indicates that this rule will apply to all traffic originating from any of your workstations. Destination should remain as Any , since we want to do translation no matter what destination the workstation is trying to reach. Service should also remain as Any , since we are not restricting this translation to any particular service type.

In the Translated Packet section, set the Source to ExternalFW by choosing Add (Hide) from the drop-down menu. This means that all traffic originating from your workstations will appear to external hosts to be originating from the firewall s routable external address. The Add (Hide) option is used for many-to-one translations. If we were translating this network to a network of the same size , we could apply the less commonly used Static option. Again, Destination and Service should be set as Original , since we are only concerned with translating source addresses here, not about destinations or services. Install On should be set to include any firewall which will be performing this translation (in this case it will be ExternalFW), and it is always a good idea to add a comment to describe the rule ” Hide rule for Office Network ”172.17.3.0/24 is a good description. See Figure 5.2 for the completed rule.

Figure 5.2: Completed NAT Rule

In addition to adding the translation rule, you must also ensure that the security policy will allow your workstations to pass traffic; the translation rule itself does not imply that packets going to and from your network will be allowed. Figure 5.3 displays what this rule should look like.

Figure 5.3: Rule to Allow Outbound Traffic

This rule, rule 4 in Figure 5.3, has source LAN , destination and service Service_Net (Negate), and action Accept . This means that all traffic originating from any of your workstations not directed to the Service_Net will be allowed outbound. Of course, because we have already configured the translation rule, once the firewall accepts traffic from any of these objects, it will then go on to translate the packets as specified.

Routing and ARP

Address Resolution Protocol (ARP) translates IP addresses to hardware MAC addresses, and vice-versa. In the example above, where we used hide-mode NAT to translate packets going to and from your internal network, we used the firewall s external IP address as the translated address. In this case, there are no ARP issues to consider because the firewall will respond to requests directed to its own external address.

However, if we were to use another routable address as the translated address, we would have to ensure that this address is published, so that when external hosts send traffic to this address, the firewall responds. To do this, you must add a static ARP entry to the host on which the firewall is installed. There is also an option, enabled by default on new NG installations but not upgrades, that enables the automatic addition of ARP entries by the firewall. This is discussed in more detail later in the chapter.

On a Solaris system, use the following syntax to add the static ARP entry:

 arp -s <translated IP> <MAC address> pub 

The MAC address to use here is the MAC address of the external interface of your firewall. You can determine this address using the ifconfig -a command. Note that this ARP entry will only exist until the system is rebooted. To make the ARP entry permanent, you will have to add it to the appropriate startup file on your system. For example, we will say that the public IP address for the Web Server is 11.12.13.10, and that the MAC address on the external interface of the firewall is 00:01:03:CF:50:C9. The ARP command you would use in this case is as follows :

 arp -s 11.12.13.10 00:01:03:CF:50:C9 

Similarly, in Windows NT, you would also need to add a static ARP entry. However, NT does not allow this via the arp command, and so you must edit the file $FWDIR\state\local.arp. In this file, add a line as follows:

 <translated IP>     <MAC address> 

Or, in our example:

 11.12.13.10          00:01:03:CF:50:C9 

On both Windows and Solaris, you can display a list of current ARP entries by issuing the command arp “a. This will include any manual ARP entries you have created, as well as all other ARP entries the system has learned. When entering the arp command, separate the fields with a space or tab. After editing this file, you will have to stop and restart the FW-1 service to activate your changes.

If you are using a Nokia to configure a static ARP entry, access the Voyager GUI select Config ARP , and add the entry. You should select the Proxy Only type. Note that if you are using VRRP, and you use the virtual IP address as the hiding address, there is no need to add a static ARP entry because the firewall already knows that it should respond to the specified address.

In addition to ARP issues, you need to keep routing issues in mind when configuring any type of NAT. Our example above does not present any obvious routing issues, assuming the workstations are all directly connected to the firewall, and are used as a gateway. However, if there were a router or any other Layer 3 device between the workstations and the firewall, you would have to ensure that the router forwarded traffic between the workstations and the firewall properly.

One other routing issue to take into account is that if the IP address you are using as your hiding address is not part of your firewall s external interface, external routers may not know how to reach this address. If traffic does not reach the firewall, then the ARP entry you created for that address will do no good. To ensure that traffic reaches the firewall, you will have to ensure that the router responsible for announcing your networks also publishes the network you are using for NAT. This may involve contacting your Internet provider (if you do not manage your own router).