Yes that is normal, especially when you configure "pair of hosts" as there will be a new Phase 2/IPSec tunnel created for every possible combination of hosts communicating through the VPN. Here is the overall process and how the various VPN Tunnel Sharing settings fit into it:
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 simply 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 as a result.
- 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. This directive will almost certainly need to be employed when setting up interoperable VPNs with Juniper, Fortinet, & Sonicwall as these vendors are quite picky about what subnets/Proxy-IDs they will accept in a Phase 2 proposal.
Also note that the ability to define a separate VPN domain per individual VPN Community is on the roadmap and will hopefully become available at some point. Edit: The ability to override VPN domains per-VPN Community was added in R80.40.
--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com
Attend my online "Be your Own TAC: Part Deux" CheckMates event
March 27th with sessions for both the EMEA and Americas time zones
