what information do we need from the remote site customer when creating site to site VPN?

[jamal_shah]

Hi,

what information do we need from the remote site customer when creating site to site VPN?

[PhoneBoy]

At a very high level:

• Remote subnets you will access
• Remote subnets that will access your resources
• The agreed-upon encryption algorithms

It gets a bit more complicated if both ends of the VPN are using the same address space.

See more here: Site to Site VPN R80.10 - Part of Check Point Infinity 

[Danny]

You need to exchange information with the remote site customer as he needs to configure the VPN on his side as well and therefore needs to know the external IP address of your VPN gateway, encryption domain, encryption settings and other data.

Best practice is to fill out a VPN Datasheet like this one:

VPN Site 1	VPN Site 2
Company A	Company B
Requested by:	Requested by:
Planning contact:	Planning contact:
Responsible for installation:	Responsible for installation:
VPN Gateway
Hardware Vendor & Version: Check Point R__.__	Hardware Vendor & Version:
External IP address:	External IP address:
Encryption Domain / Crypto Map: Additional NAT-IPs if Source NAT is required:	Encryption Domain / Crypto Map:
VPN Phase 1 (IKE)
Key Management: IKEv1 for IPv4, IKEv2 for IPv6 IKEv2 only Prefer IKEv2, support IKEv1	Key Management: IKEv1 IKEv2 Prefer IKEv2, support IKEv1
DH-Group (Diffie-Hellman): Group 1 (768 bit) Group 2 (1024 bit) Group 5 (1536 bit) Group 14 (2048 bit) Group 19 (256-bit ECP) Group 20 (384-bit ECP)	DH-Group (Diffie-Hellman):
Encryption Algorithm: AES-256 3DES DES CAST GOST	Encryption Algorithm:
Hash / Data Integrity: MD5 SHA1 SHA-256 (SHA-2) SHA-384 (SHA-2) AES-XCBC	Hash:
Pseudo Random Function (PRF): No Yes: SHA-256 (SHA-2)	Pseudo Random Function (PRF): No Yes:
Authentication Method: Certificate Pre-Shared Secret	Authentication Method: Certificate Pre-Shared Secret
SA Lifetime / Renegotiation time: 1440 min. (Default)	SA Lifetime:
VPN Phase 2 (IPSec)
Encapsulation: ESP	Encapsulation: ESP
Perfect Forward Secrecy (PFS): Yes / No	Perfect Forward Secrecy (PFS): Yes / No
DH-Group (Diffie-Hellman): Group 1 (768 bit) Group 2 (1024 bit) Group 5 (1536 bit) Group 14 (2048 bit) Group 19 (256-bit ECP) Group 20 (384-bit ECP)	DH-Group (Diffie-Hellman):
Encryption Algorithm: 3DES AES-128 AES-256 AES-GCM-128 AES-GCM-256 DES CAST GOST DES-40CP CAST-40 NULL	Encryption Algorithm:
Hash / Data Integrity: MD5 SHA1 SHA-256 (SHA-2) SHA-384 (SHA-2) AES-XCBC	Hash:
Aggressive Mode: Yes / No	Aggressive Mode: Yes / No
SA Lifetime: 3600 sec. (Default)	SA Lifetime:
VPN Tunnel Sharing
One VPN tunnel per each pair of hosts One VPN tunnel per subnet pair (Default) One VPN tunnel per Gateway pair
VPN NAT Options
Disable NAT inside the VPN traffic: Yes / No
VPN Interesting Traffic
Inbound from Site 2:	Inbound from Site 1:
Outbound to Site 2:	Outbound to Site 1:

[Timothy_Hall]

A great worksheet, just want to emphasize that the Phase 1 SA Lifetime is expressed by Check Point in minutes, while the Phase 2 SA Lifetime is expressed by Check Point in seconds.  Most other vendors express both values in seconds. 

If these values are mismatched between the two sites the VPN will still start and appear to work, but for an interoperable VPN situation in particular Delete SAs don't always work correctly.  This will cause seemingly random hangs of the VPN tunnel that can be rectified by killing the tunnel via "vpn tu", at which point the VPN will immediately pop back up and start working...until the hang happens again.  Also watch out for early tunnel expirations due to a Data Lifesize limit being reached or a VPN idle timer expiring.  Enabling Permanent Tunnels (and enabling DPD with it for interoperable VPNs) is strongly recommended.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[besal_mon]

For Phase 1 Encryption Algorithm:

• AES-256

Is it CBC or ECB?

[Timothy_Hall]

Pretty sure it is CBC: sk105119: Best Practices - VPN Performance

--
My Book "Max Power: Check Point Firewall Performance Optimization"
Second Edition Coming Soon

[PhoneBoy]

That is very helpful

[Vladimir]

Danny,

Can you post the .doc version of the VPN worksheet?

[Danny]

I created the above datasheet from scratch within this Jive portal using html tables and standard text formatting. Therefore I don't have a .doc version but you should be able to easily copy it from here into any .doc.

[Vladimir]

Thanks Danny. I've exported it to a document and copy/pasted it in Word and it looks fine.

I'd like to ask you a question though: for Check Point to Check Point externally managed gateway, one of the pre-requisites is the topology data exchange and it is not included in this document.

Is it still a requirement in R80.10 (I believe it is referencing older documents in the R80.10  Advanced VPN Configuration Guide) and if so, can you add it to your template?

Thank you.

[Danny]

In my experience this is not a pre-requisite. I'm using many of these configurations and never exchanged the entire topology data, just the networks that are part of the interesting traffic.

[Vladimir]

Can someone from Check Point provide a definitive answer to the topology exchange requirements between externally managed gateways?

According to the Advanced VPN Configuration Guide:

To configure a VPN using pre-shared secrets, with the external Security Gateways as satellites in a star VPN Community, proceed as follows:

1. Define the Network Object(s) of the Security Gateways that are internally managed. In particular, be sure to do the following:
   • In the General Propertiespage of the Security Gateway object, select VPN.
   • In the Topologypage, define the Topology, and the VPN Domain. If the VPN Domain does not contain all the IP addresses behind the Security Gateway, define the VPN domain manually by defining a group or network of machines and setting them as the VPN Domain.
2. Define the Network Object(s) of the externally managed Security Gateway(s).
   • If it is not a Check Point Security Gateway, define an Interoperable Device object from: Manage > Network Objects... > New... > Interoperable Device...
   • If it is a Check Point Security Gateway, In the Network Objectstree, right click and select New > Check Point > Externally Managed Security Gateway....
3. Set the various attributes of the peer Security Gateway. In particular, be sure to do the following:
   • In the General Propertiespage of the Security Gateway object, select VPN (for an Externally Managed Check Point Security Gateway object only).
   • In the Topologypage, define the Topology and the VPN Domain using the VPN Domain information obtained from the peer administrator. If the VPN Domain does not contain all the IP addresses behind the Security Gateway, define the VPN domain manually by defining a group or network of machines and setting them as the VPN Domain.
4. Define the Community. The following details assume that a Star Community was chosen, but a Meshed Community is an option as well. If working with a Mesh community, ignore the difference between the Central Security Gateways and the Satellite Security Gateways.
   • Agree with the peer administrator about the various IKE properties and set them in the VPN Propertiespage and the Advanced Properties page of the community object.
   • Define the Central Security Gateways. These will usually be the internally managed ones. If there is no another Community defined for them, decide whether or not to mesh the central Security Gateways. If they are already in a Community, do not mesh the central Security Gateways.
   • Define the Satellite Security Gateways. These will usually be the external ones.
5. Agree on a pre-shared secret with the administrator of the external Community members. Then, in the Shared Secretpage of the community, select Use Only Shared Secret for all External Members. For each external peer, enter the pre-shared secret.
6. Define the relevant access rules in the Security Policy. Add the Community in the VPNcolumn, the services in the Service column, the desired Action, and the appropriate Track
7. Install the Security Policy.

[PhoneBoy]

I'm pretty sure in an externally managed gateway scenario, you're not exchanging topology automatically.

Basically all it's saying is that your local definition should be the same as it is defined on the remote site (using similar subnet definitions, settings, etc). 

[Vladimir]

That I understand. The issue is that with any other device or peer, the exchange of the topology data is not required.

We are simply specifying Encryption Domain and external IP of the peer (in addition to crypto settings).

What makes Externally managed CP gateway different that it requires (if it still does) the topology data?

I am working now with one of my clients that is trying to peer with someone also running CP, but they are refusing to provide their topology data. So I am trying to get to the bottom of issue here to see if it is really a mandatory pre-requisite.