site-to-site VPN - Encryption domain issue

[mselecky]

Hello,

I am facing a strange issue. We have site-to-site VPN with 3rd party. We have Checkpoint, they have Sophos UTM. Tunnel is working only one direction. 

- Sophos >> Checkpoint - working fine

- Checkpoint >> Sophos - not working

IkeView tool says Phase1 is ok, Phase2 is failing when Checkpoint initiates the tunnel. Only QM packet 1. After that I receive an error:

Notify Payload

Next Payload: NONE
Reserved: 0
Length: 00 0c (12)
DOI: 00 00 00 01 (1)
ProtID: 1
SPI Size: 0
Notify Type: 18 (INVALID-ID-INFORMATION)

I also noticed in VPNd.ELG this:

[] vpn_ipsec_spi_notify: spi 0, 127.0.0.1, peer x.x.x.x, proto 50, my range 172.16.16.0-172.16.16.255, peer range 192.168.203.0-192.168.203.255, 

However in dashboard I have:

• My encryption domain: 172.16.16.0/24
• Interoperable device encryption domain: 192.168.200.0/22

From CLI I am getting correct enc. domain:

5:04:09 x.x.x.x > :(+);From:192.168.200.0;,To:192.168.203.255;CPTFMT_sep:;;Peer:x.x.x.x;,allowed_peers_table_id:0;,gw_conf:0;,community_id:5;,subnet_support:1;,from:192.168.200.0;,to:192.168.203.255;product:VPN-1 & FireWall-1;product_family:Network

Any ideas/hints on what to check, change to get this working?

Thanks indeed.

[Timothy_Hall]

Find a Quick Mode Key Install log from when the Sophos has initiated the VPN, I'll guarantee they aren't asking for the entire 192.168.200.0/22 from you.  In the Community setting try setting VPN Tunnel Sharing to "one tunnel per pair of hosts", reinstall policy and try again from the Check Point side.  If it works you need to configure the table.def file to more precisely control how the Check Point proposes subnets, see sk108600 Scenario 1.

[Vladimir]

The issue with 3rd party VPN interoperability keeps coming up over the years and it most often results in editing the files.

IMHO, it is a high time for Check Point to implement the GUI options for these modifications. This will not only simplify configuration, but will also allow admins to be aware of the particulars while using SmartConsole.

[mselecky]

Hi,

thanks for your reply. In IKE View tool I see this:

QM packet 1 (06:29:21) - Wed Nov 20 2019

ID:
(192.168.200.0 255.255.252.0) - (172.16.16.0 255.255.255.0)

Transport: UDP (IPv4)
PeerIP: 365675aa
PeerPort: 500
Peer Name: GW_x.x.x.x

<== Received from peer x.x.x.x

Checkpoint replied back:

QM packet 2 (06:29:21) - Wed Nov 20 2019

ID:
(192.168.200.0 255.255.252.0) - (172.16.16.0 255.255.255.0)

Transport: UDP (IPv4)
PeerIP: 365675aa
PeerPort: 500
Peer Name: GW_x.x.x.x

==> Sent to peer x.x.x.x

This when Sophos initiated communication and it works.

Tunnel management is configured to: "one tunnel per pair of hosts".

I can try to implement a suggested solution from Scenario 1, but CMA is leveraged so I have to follow the change process that can take several weeks. Is there any way how to test it from the gateway configuration perspective? Gateway is for now, under my control so I can change what I need.

Thanks indeed.

[Danny]

You need to check on the Sophos what it receives from the Check Point when Check Point is initiating the tunnel.

[mdjmcnally]

OK so Sophos is sending

(192.168.200.0 255.255.252.0) which is the /22

Check Point is sending

peer range 192.168.203.0-192.168.203.255 which is a /24

You will need to get the Check Point to send a /22 for the 192.168.200.0/22 Network for this to work

Both are sending 172.16.16.0/24 so no issue there.

Would suggest Per Subnet for the Tunnel Management which would be a SmartConsole change and Policy Installation and then recheck with the vpn debug and ikeview

[mselecky]

The strangest thing is that I have in dashboard /22, but in IKEview I see that Checkpoint sends /24 proposal.

[Danny]

Just check on your Sophos which enc domain Check Point is announcing, enter this data into your Sophos VPN configuration and you should be good. Keep in mind that Check Point also renders the external IP addresses of the VPN gateways as part of the enc domain.

[mdjmcnally · Accepted solution]

As others suggested this is going to be the old issue of the Check Point supernetting multiple subnets

Check with the Sophos EXACTLY how they have defined the EncDomain.

Have they actually defined as 192.168.200.0/22  or have they actually defined as 192.168.200.0/24, 192.168.201.0/24, 192.168.202.0/24, 192.168.203.0/24

As you are seeing vpn_ipsec_spi_notify: spi 0, 127.0.0.1, peer x.x.x.x, proto 50, my range 172.16.16.0-172.16.16.255, peer range 192.168.203.0-192.168.203.255

Then I would suggest that they have multiple /24 subnets defined and that is what they are expecting

Check Point is notorious for this with 3rd Party VPN where will supernet 

As Timothy Hall said is going to https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

and look at Scenario 1

You can then look at disabling the Supernetting and define the Remote Encryption Domain EXACTLY has they have in terms of using multiple /24 subnets rather then a single /22.

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Section 4 gives further details of the 3rd Party connectivity improvements

[mselecky]

The issue has been resolved.

• The Sophos had /22 local encryption domain, so we changed it to multiple /24 subnets
• The checkpoint had /22 remote encryption domain in the dashboard, but somehow proposed /24 (as per IKEview), So I changed the configuration in the dashboard to multiple /24 subnets.

Checkpoint tunnel management was changed to "per subnet" (per host and per gateway were rejected).

Now the tunnel is working in both directions.

Thanks all of you for such great support.