This section addresses some questions that are frequently asked about VPNs in FireWall-1.
Generally, yes. It is usually a matter of making sure the settings match on both ends of the VPN. This is made somewhat difficult because each vendor refers to a particular setting with a slightly different name. For known interoperability issues with some third-party VPN products, see FAQ 11.17.
In NG FP2 and FP3, there is an issue that requires a hotfix for interoperating with a Cisco PIX. For FP3, request hotfix SHF_FW1_FP3_0006 from Check Point Support. For FP2, request hotfix SHF_FW1_FP2_0248.
This feature should interoperate with third-party products. On IPSO, there have been problems with failovers with gateway clusters and third-party VPN products. These can sometimes be resolved by enabling the ifwd process in Voyager.
Yes, you can. You can run just about any protocol you'd like through the VPN.
Even though your encryption domain typically contains everything behind your gateway, you can set up the rules in such a way that the other site can access only certain machines. Note that this does not prevent the site from using the allowed services and destination to access other machines inside your network.
Yes, you can.
If the sites are accessible from the same interface, no. If each site is using a different interface, then it should work. In a gateway cluster configuration, this approach works in NG FP3 or above provided the Interfaces tab is defined on the gateway cluster object. This means that all IP addresses associated with the gateway cluster (the "shared" IPs) should be manually defined. However, in NG FP3, it may cause the platform to stop responding to ARP requests.
In a hub-and-spoke model, all remote sites know about only the main hub site. When a remote site (a spoke) wants to communicate with another site, including the main site or even the Internet, the data is encrypted and sent to the main site. The main site knows how to get to every spoke. The data is decrypted, reencrypted if necessary, and sent on to the appropriate site. This makes configuration of the spoke sites very easy, although it adds additional overhead because the data must traverse two sites.
FireWall-1 NG FP3 and later support this with a feature called VPN Routing. In FireWall-1 NG AI, create a Star-type VPN Community, as shown in Figure 11.21.
The General frame shows three options for VPN Routing.
To center only: This option allows a satellite gateway to talk to only the central gateway.
To center and to other satellites through center: Any satellite gateway in the VPN Community may talk to any other satellite by going through a central gateway.
To center, or through the center to other satellites, to internet and other VPN targets: A satellite gateway may communicate via a VPN to a central gateway, through which the gateway can access other VPN endpoints outside the VPN Community. Furthermore, all Internet access from a satellite site is routed through a central gateway. This allows for finer-grained control over Internet access.
In NG FP3, VPN Routing is manually defined on the management station in a file called $FWDIR/conf/vpn_route.conf. The format of the file is explained in embedded comments in the file. You will add lines that specify the destination network object (can be a network, gateway, host, or group object), the route packets destined for the network object should travel, and the gateway or group of gateways on which this route should be installed. Any changes to this file require reinstallation of the security policy on all managed nodes.
NAT is applied either before a packet is encrypted or after decryption. I usually suggest either that you create rules in your NAT rulebase that do not NAT any traffic between the encryption domains or that you use the "Disable NAT inside the VPN community" property discussed earlier in this chapter. Figure 11.22 shows an example of a rule you would use on Site A's security policy.
If you do decide to use NAT, make sure you include any translated addresses in the encryption domain.
There is one situation where you will want to use NAT with a VPN: when two sites use the same address space within their encryption domains. In this case, you will need to perform address translation to communicate with hosts in the remote site as well as provide address translation so they can talk to your hosts.
Let us assume Site A and Site B have the same encryption domain: 172.16.0.0/24. Let us also assume that Site A will translate its address space to 10.0.0.0/24 when talking with Site B. Similarly, Site B will translate its address space to 172.31.0.0/24 when communicating with Site A. Site A should define the encryption domain for itself as 172.16.0.0/24 and 10.0.0.0/24. Site A's definition for Site B's encryption domain should be 172.31.0.0/24. Site B should define its own encryption domain as 172.31.0.0/24 and 172.16.0.0/24. Site B's definition for the encryption domain for Site A should be 10.0.0.0/24.
The rules you define in this situation are identical to those for any other situation except for the NAT rules. The rules for Site A should be like those shown in Figure 11.23; for site B, like those shown in Figure 11.24. Note that no proxy ARPs or static routes should be necessary in addition to these rules.
Yes, you can. The Sample Configurations section of this chapter includes an example of how to do this.
Yes. For example, assuming gw1 is subject to static NAT and gw2 is establishing a VPN with gw1, you can configure an automatic NAT rule on gw2 (not gw1) for gw1's nonroutable address to gw1's routable address. Additionally, configure the routable address of gw1 into the interfaces list.
Absolutely. However, gateways cannot have more than one VPN Community in common with each other.