|
|
|
In This Section: |
Communicating parties need a connectivity platform that is not only fast, scalable, and resilient but also provides:
Only the communicating parties must be able to read the private information exchanged between them.
The communicating parties must be sure they are connecting with the intended party.
The sensitive data passed between the communicating parties is unchanged, and this can be proved with an integrity check.
In the Figure, host 1 and host 6 need to communicate. The connection passes in the clear between host 1 and the local Security Gateway. From the source and destination addresses of the packet, the Security Gateway determines that this should be an encrypted connection. If this is the first time the connection is made, the local Security Gateway initiates an IKE negotiation with the peer Security Gateway in front of host 6. During the negotiation, both Security Gateways authenticate each other, and agree on encryption methods and keys. After a successful IKE negotiation, a VPN tunnel is created. From now on, every packet that passes between the Security Gateways is encrypted according to the IPsec protocol. IKE supplies authenticity (Security Gateways are sure they are communicating with each other) and creates the foundation for IPsec. Once the tunnel is created, IPsec provides privacy (through encryption) and integrity (via one-way hash functions).
After a VPN tunnel has been established:
For more information regarding the IKE negotiation, see: IPsec & IKE.
Creating VPN tunnels between Security Gateways is made easier through the configuration of VPN communities. A VPN community is a collection of VPN enabled gateways capable of communicating via VPN tunnels.
To understand VPN Communities, a number of terms need to be defined:
The methods used for encryption and ensuring data integrity determine the type of tunnel created between the Security Gateways, which in turn is considered a characteristic of that particular VPN community.
A Security Management Server can manage multiple VPN communities, which means communities can be created and organized according to specific needs.
A Remote Access Community is a type of VPN community created specifically for users that usually work from remote locations, outside of the corporate LAN. This type of community ensures secure communication between users and the corporate LAN. For more information, see: Introduction to Remote Access VPN.
Before Security Gateways can exchange encryption keys and build VPN tunnels, they first need to authenticate to each other. Security Gateways authenticate to each other by presenting one of two types of "credentials":
Considered more secure, certificates are the preferred means. In addition, since the Internal CA on the Security Management Server automatically provides a certificate to each Check Point Security Gateway it manages, it is more convenient to use this type of authentication.
However, if a VPN tunnel needs to be created with an externally managed Security Gateway (a gateway managed by a different Security Management Server) the externally managed Security Gateway:
A "secret" is defined per external Security Gateway. If there are five internal Security Gateways and two externally managed Security Gateways, then there are two pre-shared secrets. The two pre-shared secrets are used by the five internally managed Security Gateways. In other words, all the internally managed Security Gateways use the same pre-shared secret when communicating with a particular externally managed Security Gateway.
The most basic topology consists of two Security Gateways capable of creating a VPN tunnel between them. Security Management Server's support of more complex topologies enables VPN communities to be created according to the particular needs of an organization. Security Management Server supports two main VPN topologies:
A Mesh is a VPN community in which a VPN site can create a VPN tunnel with any other VPN site in the community:
A star is a VPN community consisting of central Security Gateways (or "hubs") and satellite Security Gateways (or "spokes"). In this type of community, a satellite can create a tunnel only with other sites whose Security Gateways are defined as central.
A satellite Security Gateway cannot create a VPN tunnel with a Security Gateway that is also defined as a satellite Security Gateway.
Central Security Gateways can create VPN tunnels with other Central Security Gateways only if the Mesh center Security Gateways option has been selected on the Central Security Gateways page of the Star Community Properties window.
A Dynamically Assigned IP (DAIP) Security Gateway is a Security Gateway where the external interface's IP address is assigned dynamically by the ISP. Creating VPN tunnels with DAIP Security Gateways are only supported by using certificate authentication. Peer Security Gateways identify internally managed DAIP Security Gateways using the DN of the certificate. Peer Security Gateways identify externally managed DAIP Security Gateways and 3rd party DAIP Security Gateways using the Matching Criteria configuration
DAIP Security Gateways may initiate a VPN tunnel with non-DAIP Security Gateways. However, since a DAIP Security Gateway's external IP address is always changing, peer Security Gateways cannot know in advance which IP address to use to connect to the DAIP Security Gateway. As a result, a peer Security Gateway cannot initiate a VPN tunnel with a DAIP Security Gateway unless DNS Resolving is configured on the DAIP Security Gateway. For more information, see Link Selection.
If the IP on the DAIP Security Gateway changes during a session, it will renegotiate IKE using the newly assigned IP address.
In a star community when VPN routing is configured, DAIP Security Gateways cannot initiate connections from their external IP through the center Security Gateway(s) to other DAIP Security Gateways or through the center to the Internet. In this configuration, connections from the encryption domain of the DAIP are supported.
Which topology to choose for a VPN community depends on the overall policy of the organization. For example, a meshed community is usually appropriate for an Intranet in which only Security Gateways which are part of the internally managed network are allowed to participate; Security Gateways belonging to company partners are not.
A Star VPN community is usually appropriate when an organization needs to exchange information with networks belonging to external partners. These partners need to communicate with the organization but not with each other. The organization's Security Gateway is defined as a "central" Security Gateway; the partner Security Gateways are defined as "satellites."
For more complex scenarios, consider a company with headquarters in two countries, London and New York. Each headquarters has a number of branch offices. The branch offices only need to communicate with the HQ in their country, not with each other; only the HQ's in New York and London need to communicate directly. To comply with this policy, define two star communities, London and New York. Configure the London and New York Security Gateways as "central" Security Gateways. Configure the Security Gateways of New York and London branch offices as "satellites." This allows the branch offices to communicate with the HQ in their country. Now create a third VPN community, a VPN mesh consisting of the London and New York Security Gateways.
Issues involving topology and encryption can arise as a result of an organization's policy on security, for example the country in which a branch of the organization resides may have a national policy regarding encryption strength. For example, policy says the Washington Security Gateways should communicate using 3DES for encryption. Policy also states the London Security Gateways must communicate uses DES as the encryption algorithm.
In addition, the Washington and London Security Gateways need to communicate with each other using the weaker DES. Consider the solution:
In this solution, Security Gateways in the Washington mesh are also defined as satellites in the London star. In the London star, the central Security Gateways are meshed. Security Gateways in Washington build VPN tunnels with the London Security Gateways using DES. Internally, the Washington Security Gateways build VPN tunnels using 3DES.
Individually, Security Gateways can appear in many VPN communities; however, two Security Gateways that can create a VPN link between them in one community cannot appear in another VPN community in which they can also create a link. For example:
The London and New York Security Gateways belong to the London-NY Mesh VPN community. To create an additional VPN community which includes London, New York, and Paris is not allowed. The London and New York Security Gateways cannot appear "together" in more than one VPN community.
Two Security Gateways that can create a VPN link between them in one community can appear in another VPN community provided that they are incapable of creating a link between them in the second community. For example:
London and New York Security Gateways appear in the London-NY mesh. These two Security Gateways also appear as Satellite Security Gateways in the Paris Star VPN community. In the Paris Star, satellite Security Gateways (London and NY) can only communicate with the central Paris Security Gateway. Since the London and New York satellite Security Gateways cannot open a VPN link between them, this is a valid configuration.
Configuring Security Gateways into a VPN community does not create a de facto access control policy between the Security Gateways. The fact that two Security Gateways belong to the same VPN community does not mean the Security Gateways have access to each other.
The configuration of the Security Gateways into a VPN community means that if these Security Gateways are allowed to communicate via an access control policy, then that communication is encrypted. Access control is configured in the Security Policy Rule Base.
Using the VPN column of the Security Policy Rule Base, it is possible to create access control rules that apply only to members of a VPN community, for example:
Source |
Destination |
VPN |
Service |
Action |
|---|---|---|---|---|
Any |
Any |
Community_A |
HTTP |
Accept |
The connection is matched only if all the conditions of the rule are true, that is - it must be an HTTP connection between a source and destination IP address within VPN Community A. If any one of these conditions is not true, the rule is not matched. If all conditions of the rule are met, the rule is matched and the connection allowed.
It is also possible for a rule in the Security Policy Rule Base to be relevant for both VPN communities and host machines not in the community. For example:
The rule in the Security Policy Rule Base allows an HTTP connection between any internal IP with any IP:
Source |
Destination |
VPN |
Service |
Action |
|---|---|---|---|---|
Any_internal_machine |
Any |
Any |
HTTP |
Accept |
An HTTP connection between host 1 and the Internal web server behind Security Gateway 2 matches this rule. A connection between the host 1 and the web server on the Internet also matches this rule; however, the connection between host 1 and the internal web server is a connection between members of a VPN community and passes encrypted; the connection between host 1 and the Internet web server passes in the clear.
In both cases, the connection is simply matched to the Security Policy Rule; whether or not the connection is encrypted is dealt with on the VPN level. VPN is another level of security separate from the access control level.
If you select Accept all encrypted traffic on the General page of the VPN community Properties window, a new rule is added to the Security Policy Rule Base. This rule is neither a regular rule or an implied rule, but an automatic community rule, and can be distinguished by its "beige" colored background.
VPN routing provides a way of controlling how VPN traffic is directed. There are two methods for VPN routing:
This method routes VPN traffic based on the encryption domain behind each Security Gateway in the community. In a star community, this allows satellite Security Gateways to communicate with each other through center Security Gateways. Configuration for Domain Based VPN is performed directly through SmartDashboard. For more information, see Domain Based VPN.
Traffic is routed within the VPN community based on the routing information, static or dynamic, configured on the Operating Systems of the Security Gateways. For more information, see Route Based VPN.
|
Note - If both Domain Based VPN and Route Based VPN are configured, then Domain Based VPN will take precedence. |
In the VPN Communities Properties window Excluded Services page, you can select services that are not to be encrypted, for example Firewall control connections. Services in the clear means "do not make a VPN tunnel for this connection". For further information regarding control connections, see: How to Authorize Firewall Control Connections in VPN Communities. Note that Excluded Services is not supported when using Route Based VPN.
When planning a VPN topology it is important to ask a number of questions:
VPN communities can be configured in either traditional or simplified mode. In Traditional mode, one of the actions available in the Security Policy Rule Base is Encrypt. When encrypt is selected, all traffic between the Security Gateways is encrypted. Check Point Security Gateways are more easily configured through the use of VPN communities — otherwise known as working in Simplified Mode. For more information regarding traditional mode, see: Traditional Mode VPNs.
To switch from Traditional mode to Simplified mode, select Policy> Convert to > Simplified VPN. For more information, see Converting a Traditional Policy to a Community Based Policy:
Alternatively, you can use this procedure:
In the Security Policy Rule Base, a new column marked VPN appears and the Encrypt option is no longer available in the Action column. You are now working in Simplified Mode.
To configure an internally managed VPN meshed community:
(There are instances where the VPN domain is a group which contains only the Security Gateway itself, for example where the Security Gateway is acting as a backup to a primary Security Gateway in an MEP environment.)
The network Security Gateway objects are now configured, and need to be added to a VPN community.
Note - There is nothing to configure on the VPN page, regarding certificates, since internally managed Security Gateways automatically receive a certificate from the internal CA.
A VPN tunnel is now configured. For more information on other options, such as VPN Properties, Advanced Properties, and Shared Secret, see: IPsec & IKE
Source |
Destination |
VPN |
Service |
Action |
|---|---|---|---|---|
Any |
Any |
Meshed community |
Any |
Accept |
Where "Meshed community" is the VPN community you have just defined.
A star VPN community is configured in much the same way as a meshed community, the difference being the options presented on the Star Community Properties window:
To make sure that a VPN tunnel has successfully opened:
Configuring a VPN with external Security Gateways (those managed by a different Security Management Server) is more involved than configuring a VPN with internal Security Gateways (managed by the same Security Management Server). This is because:
There are various scenarios when dealing with externally managed Security Gateways. The following description tries to address typical cases and assumes that the peers work with certificates. If this is not the case refer to Configuring a VPN with External Security Gateways Using a Pre-Shared Secret.
|
Note - Configuring a VPN using PKI and certificates is more secure than using pre-shared secrets. |
Although an administrator may choose which community type to use, the Star Community is more natural for a VPN with externally managed Security Gateways. The Internal Security Gateways will be defined as the central Security Gateways while the external ones will be defined as the satellites. The decision whether to mesh the central, internal Security Gateways or not depends on the requirements of the organization. The diagram below shows this typical topology.
Note that this is the Topology from the point of view of the administrator of Security Gateways A1 and A2. The Administrator of Security Gateways B1 and B2 may well also define a Star Topology, but with B1 and B2 as his central Security Gateways, and A1 and A2 as satellites.
The configuration instructions require an understanding of how to build a VPN. The details can be found in: Introduction to Site to Site VPN.
You also need to understand how to configure PKI. See Public Key Infrastructure.
To configure VPN using certificates, with the external Security Gateways as satellites in a star VPN Community:
http://<IP address of peer Security Gateway or Management Server>:18264
You may have to export the CA certificate and supply it to the peer administrator.
Configuring VPN with external Security Gateways (those managed by a different Security Management Server is more involved than configuring VPN with internal Security Gateways (managed by the same Security Management Server) because:
There are various scenarios when dealing with externally managed Security Gateways. The following description tries to address typical cases but assumes that the peers work with pre-shared secrets. If this is not the case refer to Configuring a VPN with External Security Gateways Using PKI.
|
Note - Configuring a VPN using PKI and certificates is considered more secure than using pre-shared secrets. |
Although an administrator may choose which community type to use, the Star Community is more natural for a VPN with externally managed Security Gateways. The Internal Security Gateways will be defined as the central Security Gateways while the external ones will be defined as the satellites. The decision whether to mesh the central, internal Security Gateways or not depends on the requirements of the organization. The diagram below shows this typical topology.
Note that this is the Topology from the point of view of the administrator of Security Gateways A1 and A2. The administrator of Security Gateways B1 and B2 may well also define a Star Topology, but with B1 and B2 as his central Security Gateways, and A1 and A2 as satellites.
The configuration instructions require an understanding of how to build a VPN. The details can be found in: Introduction to Site to Site VPN.
To configure a VPN using pre-shared secrets, with the external Security Gateways as satellites in a star VPN Community, proceed as follows:
Check Point Nodes communicate with other Check Point Nodes by means of control connections. For example, a control connection is used when the Security Policy is installed from the Security Management Server to a Security Gateway. Also, logs are sent from Security Gateways to the Security Management Server across control connections. Control connections use Secure Internal Communication (SIC).
Control connections are allowed using Implied Rules in the Security Rule Base. Implied Rules are added to or removed from the Security Rule Base, by selecting or clearing options in the Firewall Implied Rules page of the SmartDashboard Global Properties.
Some administrators prefer not to rely on implied rules, and instead prefer to define explicit rules in the Security Rule Base.
If you turn off implicit rules, you may not be able to install a Policy on a remote Security Gateway. Even if you define explicit rules in place of the implied rules, you may still not be able to install the policy:
The administrator wishes to configure a VPN between Security Gateways A and B by configuring SmartDashboard. To do this, the administrator must install a Policy from the Security Management Server to the Security Gateways.
The solution for this is to make sure that control connections do not have to pass through a VPN tunnel.
If you turn off implied rules, you must make sure that control connections are not changed by the Security Gateways. To do this, add the services that are used for control connections to the Excluded Services page of the Community object. See sk42815 for details.
|
Note - Although control connections between the Security Management Server and the Security Gateway are not encrypted by the community, they are nevertheless encrypted and authenticated using Secure Internal Communication (SIC). |
