P2 QuickMode failed: INVALID_ID_INFORMATION

[Exonix]

Hello all,

we have a S2S Tunnel between CheckPoint R80.40 and Sophos Firewall 9.713.

local encryption Domain on the CheckPoint: 11 hosts from network 192.168.0.0/24

remote encryption Domain on the CheckPoint: network 10.20.1.0/24

local encryption Domain on the Sophos: network 10.20.1.0/24

remote encryption Domain on the Sophos: network 192.168.0.0/24

everything works very good.

Now we are changing the remote encryption Domain on the Sophos to 11 hosts from network 192.168.0.0/24, so that all encryption Domains will be same on both sides. After changing the VPN works only one way: from Sophos to CheckPoint. While connection from CheckPoint [YYY] to Sophos [XXX] we see an error on Sophos: 

cannot respond to IPsec SA request because no connection is known for 10.20.1.0/24===XXX[XXX]...YYY[YYY]===192.168.0.0/24
sending encrypted notification INVALID_ID_INFORMATION to YYY:500

on the CheckPoint I also see that is trying to build SA with Network (message is below). Question: why builds CheckPoint SA with a network even in Local encryption has 11 hosts? Sophos dosn't accept this because it also has 11 hosts only.

I drew a picture to better understand. I've played with Tunnel Management - didn't help

Thank you in advance!

[Timothy_Hall]

In the properties of the VPN Community change VPN Tunnel Sharing from "pair of subnets" to "pair of hosts" if you want the Check Point to propose /32's, which is apparently what the Sophos is expecting when the Check Point is the tunnel initiator.

[the_rock]

In addition to what Tim gave you, you may need to verify all below settings in Guidbedit are set to false, as those control supernetting, which will also force CP side to send largest possible subnet(though that may not be intended)

Andy

ike_enable_supernet

ike_p2_enable_supernet_from_R80.20

ike_use_largest_possible_subnets

[Exonix]

but will it affect all the other tunnels? I think so, so it's a bit dangerous... need to discuss internally, but thank you

[the_rock]

I can only speak for myself, I must have done it at least 20 times and only once there was an issue, but this was back in R65 days, never since then. To be sure, I would get an official statement from TAC.

[Exonix]

ike_p2_enable_supernet_from_R80.20 is a setting for specific Tunnel, other settings exist only in Global Properties

I've disabled ike_p2_enable_supernet_from_R80.20 - did't help.
but - after remote site changed the local encryption domain to a host - it started working.
but - a connection to a host, which is in a newtork (we can't specify any host from this network) - stoped working...

so, is it not possible to mix host-host and host-network?

[the_rock]

You can have hosts/subnets in enc domain, but then only one option can be selected for tunnel management in the community. I had not done it that way in awhile. Last time I made that work with a customer was back in R77.30 days : - )

[Timothy_Hall]

You shouldn't need to mess around with those supernet and largest_possible_subnet variables if VPN Tunnel Sharing is pair of hosts.  The firewall will always propose /32's for both source and destination every time.  Be aware however that for every combination of IP addresses that try to communicate through the VPN, a new IPSec/Phase 2 tunnel will be created.  If PFS is set, this will cause an expensive Diffie-Hellman to be performed for every new IPSec/Phase 2 tunnel created.  If a bunch start up at once it could definitely dent your CPU utilization.  For that reason, lock down as tightly as possible in your Access Control policy what IP addresses are allowed to talk to each other through the tunnel to minimize the quantity of IPSec/Phase 2 tunnels created as much as possible.

[the_rock]

hey @Timothy_Hall ...somewhat (un)related question. I recall you saying in one of the previous posts that when you set tunnel as permanent in vpn community, value tunnel_keepalive_method is automatically set for the objects as DPD in Guidbedit. Is this starting R81 or before, cant remember now...

Andy

[Timothy_Hall]

Starting in R81 tunnel_keepalive_method will be set to DPD by default on all Interoperable Device object types.

[the_rock]

Thanks for confirming 🙌

[Exonix]

Timothy_Hall thank you for your answer. Let me explain the problem anew with all details. On one Site we have only hosts in the local ecnryption domain, on another Site we only have networks in the local encryption Domain. In that configuration only one-way traffic goes via Tunnel: from networks to hosts, but not from hosts to networks. How should we configure CheckPoint for this case?

[the_rock]

I believe below is what you need to verify.

Andy

 

[Exonix]

it is alredy impelmented and VPN Domain has hosts only:

[the_rock]

Okay...and tunnel management tab for that community is set for pair of hosts as well? If yes, then I would suggest VPN debugs or contact TAC for faster resolution.

Andy

vpn debug truncon

vpn debug ikeon

check vpnd.elg and ike.elg in $FWDIR/log dir

[Timothy_Hall]

As long as the Sophos is proposing hosts/subnets that fall into the VPN domain of the Check Point somewhere it will accept it no matter the VPN Tunnel Sharing Setting.  Based on your application data flow it sounds like the Sophos will be doing all the proposing and the Check Point will accept any proposals that are subsets, and they do not have to precisely match the subnet sizes defined in its VPN domain.

On the other hand, proposals presented to the Sophos by the Check Point must PRECISELY match the subnet sizes defined on the Sophos, subsets are not acceptable and you will blow up in Phase 2 with Invalid ID.  As long as the Sophos is the only one proposing, it doesn't matter what the VPN Tunnel Sharing option is set to on the Check Point.  The VPN tunnel is a two-way street once it successfully initializes and it doesn't matter who proposed it in the first place.

However if you would like the Check Point to be able to successfully propose and start up the VPN from its end (advisable), you will have to manually define the exact proposals you want sent to the Sophos peer to ensure they precisely match its defintions.  This is done by adding a subnet_for_range_and_peer directive to the proper *.def file on the SMS as described in Scenario 1 here: sk108600: VPN Site-to-Site with 3rd party