Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
gemechisd
Contributor

Difference between 2 packet captures

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.

0 Kudos
8 Replies
Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
gemechisd
Contributor

@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.

0 Kudos
Timothy_Hall
Champion
Champion

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?

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
(1)
the_rock
Legend
Legend

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

0 Kudos
(1)
gemechisd
Contributor

@the_rock 

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

the_rock
Legend
Legend

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

Best regards,

Andy

0 Kudos
(1)
gemechisd
Contributor

@the_rock 

Kindly have a look at it.

0 Kudos
the_rock
Legend
Legend

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events