Site to Site VPN connection Narrowed

[Uncle_Bens]

Hi,

I’m troubleshooting an IKEv2 Site-to-Site VPN between a Check Point gateway and a Forcepoint firewall, and I’m seeing unexpected Traffic Selectors.

Expected configuration

Check Point local encryption domain:

172.16.49.32/27

Remote encryption domain:

172.26.49.0/24

My Check Point gateway also has an internal interface with IP 10.0.20.1.

The 10.0.20.1 address is NOT part of the VPN encryption domain, is not configured in the VPN Community as a local network/host, and is not supposed to be advertised or used as a VPN Traffic Selector.

However, vpn tu tlist shows this unexpected SA:

Peer: x.x.x.x - XY-Firewall
Methods: ESP Tunnel AES-256 SHA256 * * * Narrow * * *
My TS: 10.0.20.1
Peer TS: 172.26.49.0/24 No outbound SPI NAT-T Connected

At the same time, the expected SA is also present:

My TS: 172.16.49.32/27 Peer TS: 172.26.49.0/24 No outbound SPI IPsec Disconnected

I also see the following Check Point VPN log:
Source: 10.0.20.1
Destination: PUBLIC IP OF THE GW VPN
Peer Gateway: PUBLIC IP OF THE GW
Scheme: IKEv2 [NAT-T (IPv4)]
Interface Name: daemon
IKE: Child SA exchange:
Exchange failed: timeout reached.
Community: XXY Reject
Category: IKE failure
Action: Reject

So the main question is:

Why is Check Point using its own internal gateway IP (10.0.20.1) as My TS for a CHILD SA when that IP is not part of the configured VPN/encryption domain?

The expected My TS is only 172.16.49.32/27.

I have other Site-to-Site VPNs configured in essentially the same way and they work correctly. This issue only occurs with this Forcepoint peer.

Could this be caused by Traffic Selector narrowing initiated by the Forcepoint, gateway-generated traffic on the Check Point, or some Check Point IKEv2 behavior/configuration that allows the gateway’s own interface IP to become a /32 Traffic Selector?

Any suggestions on what to debug/check next would be appreciated.

[_Val_]

In your SmartConsole, which IP address is used to define your FW object? I suspect it is the internal address. If so, this answers your question. GW is using its main IP address as an ID.

[Uncle_Bens]

Indeed. That's the ip which defines my FW object. But what can be the solution?

[_Val_]

One of two ways:

1. Change the GW object's IP address to the external IP, or,
2. Use Link Selection setings with "Always use..." under VPN GW tab and set the external GW IP there,

then reinstall policy and try again

[Uncle_Bens]

It is set to the external IP already

[_Val_]

You are right; I should read your original message more carefully. Since you are using an externally managed GW, the IP Selection will not help. 

If you want to get rid of the traffic selector associated with the internal IP address, you will have to redefine the GW ID with the external IP. Be careful here; you may need to add a static route on your management server if this GW is not set up as a default GW on the management side. 

Now, a different question. Why is having additional TS a problem for you? 

[Uncle_Bens]

The additional TS itself would not be a problem if the intended CHILD SA was established and traffic was working correctly.

The problem is that the expected SA:

My TS:   172.16.49.32/27
Peer TS: 172.26.49.0/24

does not establish successfully (Disconnected / No outbound SPI), while I also get this unexpected narrowed SA:

My TS:   10.0.20.1/32
Peer TS: 172.26.49.0/24
*** Narrow ***

10.0.20.1 is the Check Point gateway's Main IPv4 address. It is not part of the encryption domain configured for this VPN.

The IKEv2 trace also shows an important difference depending on which peer initiates the negotiation.

When Check Point initiates, it proposes the expected selectors:

172.16.49.32/27 <-> 172.26.49.0/24

but that CHILD SA exchange times out.

When the Forcepoint initiates, the Check Point trace shows that it proposes IPv4 Universal Range for TSi/TSr. Check Point then performs TS narrowing, and the resulting local TS becomes 10.0.20.1/32.

So my concern is not simply "there is an additional TS". I am trying to understand why the gateway's Main IPv4 address is selected during narrowing, while the explicitly configured encryption domain is 172.16.49.32/27, and why the intended CHILD SA is not being established.

If both SAs were established and the intended traffic worked, I would agree that the additional TS by itself would not necessarily be an issue.

[_Val_]

This is odd. I suggest you first get rid of the internal GW ID and then troubleshoot further. I suspect there is something else on the Forcepoint side that is causing issues.

[Uncle_Bens]

I have several S2S conenction without any issue that the Main Address is 10.0.20.1. 

I am also thinking that the issue is on the other side.... 

[_Val_]

As this is not a Forcepoint community, I am not sure how I can help any further...

[Uncle_Bens]

The 10.0.20.1/32 appears as a Narrowed My TS because the Forcepoint, when initiating IKEv2, proposes Universal Traffic Selectors (0.0.0.0/0) instead of the explicitly configured subnets.

Check Point, acting as the responder, then performs Traffic Selector narrowing. During this process, it selects 10.0.20.1/32, which is the Check Point gateway’s Main IPv4 address, as the local TS.

This is why vpn tu tlist shows:

*** Narrow ***

My TS: 10.0.20.1

Peer TS: 172.26.49.0/24

When Check Point initiates the CHILD SA itself, it correctly proposes the configured encryption domains:

172.16.49.32/27 <-> 172.26.49.0/24

So the unexpected /32 is triggered specifically by the Forcepoint’s universal TS proposal and the subsequent Check Point TS narrowing, not because 10.0.20.1 is explicitly configured in the VPN domain.

So I think they are using route based VPN. Anyway thank you for you assistance!

[_Val_]

Try checking the main IP; that might help. Also, talk to Forcepoint admins; maybe there is something they can tweak on their end

[Uncle_Bens · Accepted solution]

In route-based mode, Forcepoint negotiated using Universal Traffic Selectors (0.0.0.0/0 - 0.0.0.0/0). Check Point then performed Traffic Selector narrowing, which resulted in the unexpected:
10.0.20.1/32 - 172.26.49.0/24
Once the Forcepoint VPN was changed to domain/policy-based mode, it started negotiating with the explicitly configured encryption domains:
172.16.49.32/27 - 172.26.49.0/24
and the VPN started working correctly.

[_Val_]

Thanks for sharing.