Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Dido-Master
Participant
Participant

Site2Site vpn comunication issue

Hello mates.

I'm facing a wery wird problem with checkpoint S2S vpn comunication.

I have one tunnel between two security gateways configured and established.

The policy rules for the two machine on both sites were defined e verified correctely to comunicate on a bidiretional way, but somehow can only send packets from Machine-A to Machine-B, when i try the reverse path, the following error is presented:

Connection terminated before the Security Gateway was able to make a decision. Insufficient data passed. To learn more see sk113479

 

Can someone help, please?! Thanks!!!!!

0 Kudos
10 Replies
Lesley
Mentor Mentor
Mentor

This means machine b is not allowed to talk with machine A. This could be acl, firewall on the machine or even routing back from machine a to machine b.

The error in this case means that machine A sended traffic, syn, but there is no response, syn-ack. 

-------
If you like this post please give a thumbs up(kudo)! 🙂
0 Kudos
Dido-Master
Participant
Participant

Thanks for your contribution!

0 Kudos
PhoneBoy
Admin
Admin

This isn't a problem. From sk113479:

  • The Security Gateway did not drop the connection.
  • There is no drop print in the kernel debug.
  • The reason for the log is not necessarily because of unwanted behavior of the edge client or the server.

A Unified Policy can contain filter criteria that cannot be resolved on the connection's first packet, such as Application or Data. Therefore, on some connections, the final rule match decision occurs on the following data packets. Until the final decision is reached, the rule base accepts the incoming data packets if a rule allows it (meaning: if one of the possibly matched rules does not have a Drop/Reject action).

In scenarios where the connection ends without application data content (no data packets), or the data quantity is not sufficient for the required engine detection, the rule base issues an Accept log with the first rule that allows the traffic. This rule might not have all the applicable criteria because some have not been detected.

In other words, this is expected behavior.

0 Kudos
Dido-Master
Participant
Participant

Thanks for your contribution!!

0 Kudos
the_rock
Legend
Legend

AS @PhoneBoy indicated, this is expected, in other words, somewhere along the lines, 3 way handshake is failing and its NOT because of the fw.

Andy

0 Kudos
Dido-Master
Participant
Participant

Thanks for your contribution.

 

0 Kudos
Martijn
Advisor
Advisor

Hi,

Had the same a two weeks ago after upgrades to R81.20 and a third party VPN.
In R81.10 VPN was OK and worked both ways. After upgrade to R81.20, we had issues with traffic both ways.
Nothing was changed on the configuration. Just an upgrade.
I saw the same message in the log on insufficient traffic, but the problem starts earlier. Check the logs with the IP-address of the VPN peer. I saw IKE failures.

I have done the following to solve this.

1. Configure a specific Encryption Domain per VPN Community with a 100% match with the configuration on the VPN peer.
2. On the VPN peer object go to Tunnel Management and select 'SA per subnet pair'.
3. Install policy.
4. Reset VPN tunnel with 'vpn tu'.

It took a few minutes but VPN tunnel came back, was stable and we could send traffic both ways again.

Regards,
Martijn

 

 

the_rock
Legend
Legend

Good point actually...changing that setting could help.

Andy

0 Kudos
Dido-Master
Participant
Participant

A appreciate your contribution!

0 Kudos
Dido-Master
Participant
Participant

Thanks for your contribution!!!

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events