https://community.checkpoint.com/t5/Cloud-Firewall/Cloudgaurd-R80-10-virtual-gw-NSX-V-6-7-droping-TCP-3-way/m-p/96149#M2053 <P>That's likely and fw ctl zdebug drop should tell you why if it's not in the logs.</P> Mon, 07 Sep 2020 01:27:58 GMT PhoneBoy 2020-09-07T01:27:58Z https://community.checkpoint.com/t5/Cloud-Firewall/Cloudgaurd-R80-10-virtual-gw-NSX-V-6-7-droping-TCP-3-way/m-p/96078#M2052 <P>This is a example test capture and IPs are test IPs.</P><P>Client: 10.68.65.230&nbsp; &nbsp; &nbsp;Server:10.68.86.9:tcp443 is the communication I am looking at.</P><P>I want to understand why 3rd ACK [packet 8] doesnt have full chain captured in this "fw monitor" capture.</P><P>For example, if you look the first [SYN] you will see all (x0eth2,i1eth2, I7eth2,o1eth2,O8eth2,X0eth2) all packets in the capture.</P><P>Why I dont see that full chain for packet number 8?</P><P>Does that mean, (the 3rd packet [ACK] of tcp 3 way handshake),&nbsp; is dropped by Cloudguard?</P><P>The actual issue is the server (10.68.86.9) never recieves the ACK and hence 3 way tcp handshake never completes from server perspective and hence conenction failing.</P><P>Why I am not seeing the full chain for the 8th packet in the attahced is a puzzle to me ??</P><P>&nbsp;</P><P>&nbsp;</P> Fri, 04 Sep 2020 20:37:37 GMT https://community.checkpoint.com/t5/Cloud-Firewall/Cloudgaurd-R80-10-virtual-gw-NSX-V-6-7-droping-TCP-3-way/m-p/96078#M2052 kanishkaw 2020-09-04T20:37:37Z https://community.checkpoint.com/t5/Cloud-Firewall/Cloudgaurd-R80-10-virtual-gw-NSX-V-6-7-droping-TCP-3-way/m-p/96149#M2053 <P>That's likely and fw ctl zdebug drop should tell you why if it's not in the logs.</P> Mon, 07 Sep 2020 01:27:58 GMT https://community.checkpoint.com/t5/Cloud-Firewall/Cloudgaurd-R80-10-virtual-gw-NSX-V-6-7-droping-TCP-3-way/m-p/96149#M2053 PhoneBoy 2020-09-07T01:27:58Z