Difference between 2 packet captures

[gemechisd]

We have a public facing Application for both mobile and web. We have captured tcpdump on our gateway for both working and not working Public IP's. Can any one differentiate both captures?

Your help is much appreciated. Below you can find both working and notworking packet captures.

[Timothy_Hall]

First off, both captures are incomplete and only showing traffic in one direction.  How did you take these captures?

For the not-working capture: the only difference for SYN is that the initiating system is not requesting the TCP timestamp option and also asking for a slightly smaller TCP scale factor & window, neither of which should cause this packet to be dropped by the firewall.

Until I can see communication in both directions it is tough to say what is wrong, as I can't even see if the SYN-ACK is returning to the firewall at all in the not-working capture.  Try running "fw ctl zdebug drop" on the gateway, then try to make the application fail, this command will show you if anything in the Check Point code dropped either the SYN or the SYN-ACK for the not-working capture scenario.

[gemechisd]

@Timothy_Hall 

Thank you for the quick reply.

Let me drop a traffic on both flows. From Public to The Node, and From the node to Public.

Below you can find it.

[Timothy_Hall]

Those captures when combined show both directions but they are for different TCP connections (source port numbers do not match) so the ability to determine what is wrong is limited.  I need to see a single capture that has all the packets in both directions for a single connection.  So I'll ask again: how are you taking this capture?

It looks like the SYN-ACK is reaching the gateway but being dropped for some reason; I don't see anything wrong with the SYN-ACK itself so it must be a stateful inspection thing that is dropping it.  Search your logs for "out of state" drops or run fw ctl zdebug drop.

If this is a high volume transaction without sufficiently diverse source ports, it is possible the occasional failures could be due to source port reuse, see here: sk24960: "Smart Connection Reuse" feature modifies some SYN packets

I'm not willing to speculate further without a full capture of both directions for the same connection.  Is this traffic subject to NAT?

[the_rock]

Im with Tim on this one. I also examined both of captures you attached and we only see one direction traffic, nothing the other way around.

Andy

[gemechisd]

@the_rock 

Thanks for the reply. I have attached on the reply for @Timothy_Hall . Kindly, check it

[the_rock]

Thanks, will do. Just working on some Microsoft Azure stuff now, but will have a look soon.

Best regards,

Andy

[gemechisd]

@the_rock 

Kindly have a look at it.

[the_rock]

It might be wiser if you do remote with TAC and they can probably check it faster. All I see is bunch of retransmissions, but hard to say for sure why its happening. Did you check to see if there is any difference as far as that other IP that fails? Did it ever work? Can you do zdebug and grep for that IP?

Andy