Site-To-Site VPN with Multiple Subnets

[lucafabbri365]

Hello to all.

This is my first post here. I hope you can help me to address the investigation rightly.

SCENARIO

Main Site - Check Point R77.30

Subnets

1. 172.16.0.0/16
2. 172.29.0.0/20
3. 172.29.16.0/20
4. 172.29.32.0/22
5. 192.168.11.0/24
6. 192.168.18.0/24
7. ...etc...

Remote Site A - Cisco Meraki MX65. Subnet: 192.168.80.0/24

Remote Site B - 3rd Party Device Router/Firewall. Subnet: 192.168.85.0/24

OBJECTIVES

The objective is to have two site-to-site:

1. Main Site <=> Remote Site A; first 4 subnets of main site should be enabled/allowed to VPN traffic
2. Main Site <=> Remote Site B; first 5 subnets of main site should be enabled/allowed to VPN traffic

CONFIGURATION

Main Site Face

I created a group in Check Point including first 5 subnets. This group was specified as VPN Domain (Encryption Domain).

I created a policy rule allowing traffic from first 4 subnets to Remote Site A subnet and viceversa.

I created a policy rule allowing traffic from first 5 subnets to Remote Site B subnet and viceversa.

Remote Site A

I specified first 4 as remote subnets.

Remote Site B

I specified first 5 as remote subnets.

PROBLEM

VPNs tunnel go up, however I can reach Remote Sites A and B (and viceversa) from 1st subnet only (172.16.0.0/16).

Can you help me to address the investigation ?

Thank you,

Luca

[KennyManrique · Accepted solution]

Hi Luca,

First of all, did you defined the remote objects as Interoperable Devices? The community is defined as One VPN Tunnel per Subnet pair?

The first I can think this is a supperneting issue, where check point is trying to send the entire 172.29.X.X network instead individual ones and the IPSec association does not match for those networks.

You can check the following SK's:

VPN Site-to-Site with 3rd party on Scenario 1 - Wrong IPsec IDs are negotiated during IKE Quick Mode.

New VPN features in R77.20  on Third party connectivity improvements.

Network 5. 192.168.11.0/24 should work also right now for you.

Regards.

[lucafabbri365]

Hello Kenny,

yes, they are defined as Interoperable Devices.

I know Check Point "supernetting" behaviour, but I thought it happened when, multiple subnets were on remote site (source: One VPN Domain per Gateway, multiple encryption domains required). Here the remote site has only one subnet. Isn't it ?

I also made the change, on remote site A, for example, I specified the entire class 172.29.0.0/16 together with 172.16.0.0/16, on but the behavior is the same.

[KennyManrique]

According to SK101219:

• The "supernetting" feature enables to adjoin smaller sub-nets to a bigger one ("supernets"). This feature makes it possible to decrease the number of IPsec SAs that are created per sub-net. This feature has a problem of connectivity with third party devices. Those devices don't support "supernetting", and as a result a "no valid SA" error can occur. An optional solution for this problem can be found in sk108600 (Scenario 1), but in this solution the supernetting is disabled for all devices.
• The improvement comes to make possible disabling "supernetting" only for 3rd party VPN devices, but keep "supernetting" enabled with Check Point Security Gateways. In addition, in the current behavior with externally managed Check Point devices with "supernetting" disabled, IPsec SA is created per host, but not per sub-net. This improvement fixes this

The supernetting depends of the local configuration for some parameters on Check Point side, because of this the gateway choice (or not) to adjoin the subnets to a bigger one.

What error messages are you receiving on your VPN logs for "Key Install"? Also, when you execute "vpn tu", how many associations for IKE and IPSEC do you see?

Regards.

[EdesLC]

You can take a look at this (sk34467: Debugging Site-to-Site VPN | ) to debug your VPN.

"For exact commands, refer to sk63560 - How to run complete VPN debug on Security Gateway to troubleshoot VPN issues?."

Other good SK that can help:

How To Troubleshoot VPN Issues in Site to Site

[Timothy_Hall]

Do you have the "disable NAT in VPN Community" checkbox set in the VPN Community properties (it is not set by default).  Is it possible that all the non-172.16.0.0/16 subnets are getting NATted to an address the Cisco is not expecting?

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

[lucafabbri365]

Hello,
yes "disable NAT in VPN Community" is checkbox selected. Consider we have lot of site-to-site VPNs configured between Check Point and 3rd party devices (Cisco Meraki, FortiGate, Cisco 871, SonicWALL). The described issue appears with some of them (not all). I'm pretty sure it is related to bad/wrong subnet advertisement over the tunnel, like Cisco Meraki support underlined by analyzing logs.

I'll try to enable VPN debug to know what is happening during tunnel connection.

I'll give feedback here.

Thank you guys.

[John_Tammaro1]

Have you considered that the issue may be over at the peers side and they may have got their policy configuration wrong ? 

[lucafabbri365]

Hello ALL,

thank you to all of your suggestion, I found "the issue": as you wrote it was supernet related issue.

Check Point supernets two 172.29.0.0/20 and 172.29.16.0/20 into only one network 172.29.0.0/19. I found it by analyzing Check Point SmartLogs for another working VPN. I noticed it supernets the two networks above:

So after fixed it into 3rd party device for not-working VPNs, all start working fine.

Probably if I didn't have working VPN, the only way to know how Check Point supernet two adiacent networks, was to enabled debug, is it right ?

Thank you,
Luca

[PhoneBoy]

Correct, the appropriate debugs should have turned this up.

[kb1]

hi can you tell me how op was able to find the ike ids (referring to his reply just above you with the supernetted id) , how can i find that as well? can that be found out using the ike view utility? or is there some other way? i just want to know what value the checkpoint supernets a bunch of subnetworks to so that it will be easier to troubleshoot in case something goes wrong when establishing a vpn.

[Magnus-Holmberg]

Honestly i would do either 2 ways.
due to the lack of logs without ike view.

- Update to R80.40 and have the possibility within GUI to specify the subnets directly on the community.

If you dont run R80.40 then.
- Configure in user.def so that you have full controll over what is sent over the tunnel.
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

How to find the user.def
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

The "subnet_for_range_and_peer" table is designed to force Check Point Security Gateway to negotiate IPsec SAs using a specific subnet mask for a given IP address range:

subnet_for_range_and_peer = {
<peerGW_IP, first_IP_in_range1, last_IP_in_the_range1; subnet_mask>,
<peerGW_IP, first_IP_in_range2, last_IP_in_the_range2; subnet_mask>,
... ... ...
<peerGW_IP, first_IP_in_rangeN, last_IP_in_the_rangeN; subnet_mask>
};

"

Example 1:

#ifndef __user_def__ 
#define __user_def__ 
// 
// User defined INSPECT code
//
subnet_for_range_and_peer = {
<192.168.10.20, 10.10.0.1, 10.10.0.254; 255.255.255.0>,
<192.168.20.20, 10.10.0.1, 10.10.255.254; 255.255.0.0>
};
#endif /* __user_def__ */

In this example, the configuration would work in the following way:

• For the VPN peer 192.168.10.20, the network IP used in the IPsec SA would be 10.10.0.0/24
• For the VPN peer 192.168.20.20, the network IP used in the IPsec SA would be 10.10.0.0/16

"


Keep inmind in R80.20 you can disable supernetting per community.

[kb1]

thank you sir