Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
jamal_shah
Participant

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

Hi,

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

16 Replies
PhoneBoy
Admin
Admin

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 

0 Kudos
Danny
Champion Champion
Champion

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 1VPN Site 2
Company ACompany 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:

Authentication Method:

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
Legend Legend
Legend

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
besal_mon
Explorer

For Phase 1 Encryption Algorithm:

  • AES-256

Is it CBC or ECB?

0 Kudos
Timothy_Hall
Legend Legend
Legend

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

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
PhoneBoy
Admin
Admin

That is very helpful Smiley Happy

0 Kudos
Vladimir
Champion
Champion

Danny,

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

0 Kudos
Danny
Champion Champion
Champion

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.

0 Kudos
Vladimir
Champion
Champion

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.

0 Kudos
Danny
Champion Champion
Champion

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.

0 Kudos
Vladimir
Champion
Champion

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.
0 Kudos
PhoneBoy
Admin
Admin

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). 

0 Kudos
Vladimir
Champion
Champion

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.

0 Kudos
CheckPointerXL
Advisor
Advisor

Is this table still valid? Im my opionion, yes

any suggestion appreciated

thank you

0 Kudos
kritik
Explorer

Thank you very much for the table.

A quick question, we face a requirement to use AES-GCM-256 algorithm in phase 1.

I guess this is still not supported, is it?

( gw: R81.10 jhf 78 )

 

Thanks again.

0 Kudos
PhoneBoy
Admin
Admin

AES-GCM-256 should be supported from R80.30 "out of the box" and will work with R80.10/.20 with the relevant JHF level per: https://support.checkpoint.com/results/sk/sk152832 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events