CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


Tim Hall has done it again! He has just released the 2nd edition of "Max Power".
Rather than get into details here, I urge you to check out this announcement post.
It's a massive upgrade, and well worth checking out. -E

 

Results 1 to 4 of 4

Thread: IKE Phase 2 Quick mode VPN encryption domain matching process

  1. #1
    Join Date
    2012-07-10
    Location
    Zurich, Switzerland
    Posts
    257
    Rep Power
    7

    Default IKE Phase 2 Quick mode VPN encryption domain matching process

    How does the IKE quick mode negotiation processs for the encryption domain work in detail on a Check Point Gateway (R77).

    Let's take the following example:

    The encryption domain for the local Check Point GW is defined as 172.16.0.0/16.
    Will the local Gateway accept a proposal from a remote interoperable device for any subnet (or even hosts) out of the 172.16.0.0/16 range?

    e.g. Proposal "Host 172.16.42.89" is accepted as well as proposal "net 172.16.33.0/24"

    Or in general: The Check point Gateway accepts any proposal from the remote side as long as the proposed subnet ist smaller than or equal to the defined encryption domain

  2. #2
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,226
    Rep Power
    13

    Default Re: IKE Phase 2 Quick mode VPN encryption domain matching process

    Quote Originally Posted by slowfood27 View Post
    How does the IKE quick mode negotiation processs for the encryption domain work in detail on a Check Point Gateway (R77).

    Let's take the following example:

    The encryption domain for the local Check Point GW is defined as 172.16.0.0/16.
    Will the local Gateway accept a proposal from a remote interoperable device for any subnet (or even hosts) out of the 172.16.0.0/16 range?
    If acting as the responder, the Check Point will accept a fully-contained subset of that subnet, yes.

    e.g. Proposal "Host 172.16.42.89" is accepted as well as proposal "net 172.16.33.0/24"
    Yes.

    Or in general: The Check point Gateway accepts any proposal from the remote side as long as the proposed subnet ist smaller than or equal to the defined encryption domain
    Yes. Just like Cisco.
    --
    Second Edition of my "Max Power" Firewall Book
    Now Available at http://www.maxpowerfirewalls.com

  3. #3
    Join Date
    2012-07-10
    Location
    Zurich, Switzerland
    Posts
    257
    Rep Power
    7

    Default Re: IKE Phase 2 Quick mode VPN encryption domain matching process

    Thx for your replies, that's clear so far.

    What is the decision process on the local CP Gateway?
    On one side, we have the source IP of the encryption rule, on the other hand we have the entries of the local encryption domain group.
    The local encryption domain group contains ALL possible entities of ALL existing site-to-site VPNs.
    So how does the local CP GW decide what host or subnet to annouce when negotiating Phase 2 with a specific peer?

  4. #4
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,226
    Rep Power
    13

    Default Re: IKE Phase 2 Quick mode VPN encryption domain matching process

    Quote Originally Posted by slowfood27 View Post
    Thx for your replies, that's clear so far.

    What is the decision process on the local CP Gateway?
    On one side, we have the source IP of the encryption rule, on the other hand we have the entries of the local encryption domain group.
    The local encryption domain group contains ALL possible entities of ALL existing site-to-site VPNs.
    So how does the local CP GW decide what host or subnet to annouce when negotiating Phase 2 with a specific peer?
    The size of the object (i.e. host or network w/ mask) used in the Firewall/Network policy layer permitting the VPN traffic does not matter as far as what is proposed by the Check Point in Phase 2, it just needs an Accept action for anything to happen at all.

    One accepted, the Check Point looks at the destination IP address and which VPN peer's VPN domain it falls into.

    Once the VPN peer is selected, next it determines what VPN Community that peer is a member of so it knows what VPN settings to use for the proposal.

    Once IKE Phase 1 is complete, to determine what to propose in Phase 2 as far as subnets, the firewall first looks at the "VPN Tunnel Sharing" settings on the VPN peer object. By default this set to "use the community settings" which means it will follow the "VPN Tunnel Sharing" settings on the VPN Community object itself. The VPN Tunnel Sharing setting defined on the VPN peer object will take precedence if it is not set to "use the community settings".

    Regardless of where VPN Tunnel Sharing is set, here is what the settings mean:

    • One VPN tunnel per pair of hosts - Propose /32's for both source and destination IP address, note that this can potentially cause a very large number of Phase 2/IPSec tunnels to start and should only be used for testing purposes, or if only a few hosts on each end need to communicate and the security policy is locked down tight to reflect this (i.e. multiple networks on each end are NOT allowed to talk to each other).

    • One VPN tunnel per subnet pair - (default setting) By default propose the "largest possible subnet" for both source and destination IP addresses. So if the VPN domain for the Check Point is 192.168.0.0/16 and the VPN domain for the peer is 10.1.1.0/24, that is exactly what the Check Point will propose. Note that if you have adjacent subnets defined in your firewall's VPN domain on the proper subnet boundary, such as 192.168.2.0/24 and 192.168.3.0/24, the Check Point by default will "roll them up" and propose 192.168.2.0/23 for the source! The VPN peer is probably not expecting this, and Phase 2 will fail.

    • One VPN tunnel per gateway pair - Propose a universal tunnel which is 0.0.0.0/0 for source and 0.0.0.0/0 for destination. This should generally only be used for a route-based VPN setup involving VTIs.


    The proposal of subnets can be controlled much more precisely through use of the subnet_for_range_and_peer directive, see scenario 1 of sk108600: VPN Site-to-Site with 3rd party for how to set this up.
    --
    Second Edition of my "Max Power" Firewall Book
    Now Available at http://www.maxpowerfirewalls.com

Similar Threads

  1. Phase 2 Quick mode failed
    By laf_c in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 2
    Last Post: 2017-07-24, 07:21
  2. Encryption Domain Match Up
    By catatonic in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 1
    Last Post: 2012-11-14, 14:19
  3. Won't NAT in Encryption Domain
    By menz456 in forum NAT (Network Address Translation)
    Replies: 1
    Last Post: 2010-02-01, 19:00
  4. Encryption domain
    By rewind in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 2
    Last Post: 2008-07-24, 10:41
  5. What should my encryption domain be?
    By Barry J. Stiefel in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 0
    Last Post: 2005-08-13, 01:59

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •