Sample Configurations

The following three situations are representative of those I have experienced in the real world. Each is designed to demonstrate what people typically do with site-to-site VPNs and how the situations are implemented on the chosen platform. All of the sample configurations are done in Simplified mode.

Creating a Three-Site VPN

The Situation

You are the firewall administrator for a company that has several sites. The main sites are in Seattle (the corporate headquarters), Sacramento, and London. Until recently, a private WAN was used to connect the various sites to one another. It is now desirable to use a VPN based on Check Point FireWall-1 to connect these sites because this choice is more cost-efficient. The main management console in Seattle manages the firewalls at the remote sites. No NAT is involved. Assume that all IPs are routable. Figure 11.26 shows a simplified network diagram.

The Goals

• Allow all hosts behind each of the three networks to communicate with each other unencumbered.

• Allow the remote firewalls to be remotely managed over the Internet.

• All sites are allowed to access sites on the Internet via FTP, HTTP, or HTTPS.

• SMTP can originate from predefined SMTP servers inside the Seattle network to the Internet (they are in a group called SMTP-Servers).

• SMTP can go to the external-smtp server from anywhere (external-smtp-server is already defined).

• Deny all other traffic.

The Checklist

• Define the encryption domains for each site.

• Define the firewall workstation objects for each site.

• Configure the firewall workstation objects for the correct encryption domain.

• Create and configure a VPN Community.

• Create the necessary encryption rules.

• Install the security policy.

• Make the appropriate changes to the internal routing to allow traffic to flow through the firewalls across the VPN.

The Implementation

You first need to define the encryption domain for the three sites. Seattle's encryption domain is:

• 10.0.0.0/255.0.0.0 (or 10.0.0.0/8)

• 172.16.0.0/255.255.0.0 (or 172.16.0.0/16)

Define network objects for both of these networks. Place them in a group called seattle-encdomain.

Similarly, for Sacramento, the encryption domain contains 172.17.0.0/255.255.0.0 (or 172.17.0.0/16). Define a network object for this network. Even though it is only one object, place it into a group called sacramento-encdomain. This makes it easier to expand later.

Similarly, for London, the encryption domain contains 172.18.0.0/255.255.0.0 (or 172.18.0.0/16). Define a network object for this network. Place it into a group called london-encdomain.

Chances are, these firewalls have been remotely managed, so you probably do not need to create the Check Point gateway objects. However, you need to modify the objects to ensure they have the correct encryption domains.

Now create a VPN Community called MyIntranet. Add the Seattle, London, and Sacramento gateways into the encryption domain. For maximum security, configure the VPN Community with the settings shown in Figures 11.27 and 11.28.

You can then create all the necessary rules, which are shown in Figure 11.29.

Notes

This is a somewhat simplified example. Most sites have far more complex security policies. Just make sure your VPN rules are listed before any rules that allow outbound traffic to the Internet.

Adding a Business Partner to the VPN Mesh

The Situation

A business partner would like to be able to come in and update information on a particular UNIX Web server at the Seattle site's DMZ (172.16.0.80). The information would be transferred via Telnet or FTP. Because the information is very confidential in nature, it would be desirable to do this in a secure fashion. Because the business partner also uses FireWall-1, a site-to-site VPN is desired. To make the configuration easier, the company will use pre-shared secrets. There is no reason to access the partner site through the VPN, so only one-way access is needed. In addition to being encrypted, strong authentication is desired. It is deemed impractical to do the authentication on the UNIX Web server, so the firewall needs to be able to provide this functionality. SecurID will be used to provide authentication.

In the context of this sample configuration, the local site refers to Seattle, and the remote site refers to the partner site. Figure 11.30 shows the new network map.

The Goals

• Maintain the previous security policy as much as possible (from the previous configuration).

• Allow the remote site to access 172.16.0.80 via FTP and Telnet with authentication using SecurID authentication, and encrypt the communication.

The Checklist

• Define the encryption domains for each site.

• Define the firewall workstation objects for each site.

• Configure the gateway objects for the correct encryption domain.

• Configure the extranet community with the appropriate gateways and objects.

• Create the necessary encryption rules.

• Configure the encryption properties for each encryption rule.

• Install the security policy.

The Implementation

On the local site's management station, you need to create an encryption domain for the remote site's encryption domain, which is 172.31.0.0/16. For this example, call it partner-encdomain. Create an externally managed Check Point gateway object called partner-fw. Define it with its external IP and check the VPN-1 Pro box. Go to the Topology frame and configure the encryption domain to be the group partner-encdomain.

At the partner site, you need to create an encryption domain for the remote site (which, in this case, is Seattle). Even though the only host that will be accessed is the Web server at 172.16.0.80, you need to add everything on that network segment to the encryption domain or you will have problems establishing the VPN. Create an object for the network 172.16.0.0/16 and add it to the group seattle-encdomain.

On both management consoles, create a new VPN Community called Extranet. Both Seattle's firewall and the partner site's firewall are added to this community. Set the VPN Properties and Advanced Properties frames as shown earlier in Figures 11.27 and 11.28. Go to the Shared Secret frame and check the "Use only Shared Secret for all External Members" box. Select the other firewall, click on Edit, type in the shared secret that was exchanged in a secure channel with the administrator of the partner site, and click OK.

At the partner site, the administrator simply needs to create a rule permitting VPN access within the community (see Figure 11.31).

At the Seattle site, the configuration is a little more complicated. You have to create users for the partner site. Let's say two people are going to be performing the updates, Ren and Stimpy. Create the users with SecurID authentication. Place the two users into a group called partner-users. (The Creating Groups subsection of Chapter 8 explains why you need to do this.) Next, create the appropriate rules. Figure 11.32 shows the complete rulebase.

The new rule in this rulebase is Rule 5, which performs authentication and encryption. Make sure you right-click on the User Auth action, edit the properties, and make sure "All servers" is selected. (The Setting Up User Authentication section of Chapter 8 explains why you need to do this.) Also note that Rule 3 was modified to include the partner site.

Install the security policy and test the new configuration.

Notes

While it seems unlikely that one business partner might issue SecurID cards to another, it does happen.

Switching the Seattle Firewall to a Gateway Cluster Configuration

The Situation

This configuration uses the previous configuration except a pair of Nokia IP530s is replacing the Seattle firewall, configured in a gateway cluster configuration for High Availability and redundancy.

All other configurations remain identical. The network map is also identical except that the Seattle-FW site has two firewalls instead of one. The new "virtual" firewall created by the gateway cluster will have the same IPs as the old firewall, so only minimal changes will be necessary at the remote sites. Figure 11.33 shows the new network diagram.

The Goals

• Convert the Seattle site into a gateway cluster configuration.

• Maintain the security policy from the previous configuration as much as possible.

The Checklist

• Create a gateway cluster object for the Seattle site, defining encryption parameters.

• Define the gateway objects for Firewall A and Firewall B, making them part of Seattle's gateway cluster.

• Modify the VPN Community to include the gateway cluster.

• Install the security policy.

The Implementation

As part of bringing the gateway cluster into existence, you must also configure VRRP Monitored Circuits or Clustering on the Nokia Security Platforms. This should be done first. Although not covered in this text, Resolution 1214 in Nokia's Knowledge Base covers configuring VRRP sufficiently well. For the purposes of this exercise, Firewall A is the primary firewall, and Firewall B is the secondary firewall (i.e., it will take over if Firewall A fails). A crossover cable will be used between the two platforms, with IP addresses 172.30.0.2 and 172.30.0.3 for Firewall A and Firewall B, respectively. This will be the network where State Synchronization runs.

You have to create new gateway objects for Firewall A (seattle-fwa) and Firewall B (seattle-fwb). Configure them as if they were standalone firewalls, but don't add them to any VPN Communities. Before Firewall A and Firewall B can be added to the gateway cluster object, you need to remove them from any VPN Communities they might be in. This won't be an issue for newly created objects, but if you simply renamed your old seattle-fw object as seattle-fwa and didn't remove it from its VPN Community, you would not be able to add seattle-fwa to a cluster because it would still be a member of a VPN Community.

Now create the gateway cluster object, adding seattle-fwa and seattle-fwb to it. Configure the Topology frame. Add the VRRP IP addresses on each interface to the Topology frame, as shown in Figure 11.34.

Configure state synchronization in the State Synchronization frame. Configure the 172.30.0.0/24 network as the synchronization network in the gateway cluster object (see Figure 11.35).

Go to the Authentication frame and verify that SecurID is set on the Authentication tab of this object (remember that the partner site must authenticate with HTTP or Telnet using SecurID authentication). You will have to exit the gateway cluster object definition and reenter it in order to add the object to the Extranet and MyIntranet VPN Communities.

In FireWall-1 NG FP3 and above, the gateway objects for seattle-fwa and seattle-fwb will completely disappear from the objects tree. This is perfectly normal.

The rulebase essentially remains the same on both sides except that all references to seattle-fw are replaced with seattle-gc.

I have not discussed the changes that need to be made on the partner end of the VPN. All you need to do is define the Interfaces tab on the seattle-fw workstation object so that it includes all IP addresses on both members of the cluster, including VRRP addresses. The interfaces' names and netmasks are not important because you are not setting up anti-spoofing (that is a bit difficult to do on a firewall you do not control!). The Topology frame should look something like Figure 11.36 when you are done.

Once both sets of changes are made, you can install and test the security policy.