TCP Repeated Connect

[ckarail]

Hi, we are evaluating CAPSA. But we have a problem with "tcp repeated connect" diagnosis entry. Although it is configured in main configuration window, sniffing sessions do not report any such type of diagnostics. Since we are sniffing firewall port, we should have many entries for "tcp repeated connect" diagnosis because the firewall will be dropping many connections through firewall rules. Any idea? Thanks in advance

[Nelson]

Before everything, I think it is neccessry to know what the topo is in your network.

If the firewall works like a internal/external protecter such as PIX, ASA, then, you must have Capsa deployed outside of your firewall, to capture and analyze the WAN link rather than the LAN port. However most of our clients deploy the Capsa for the internal communication analysis.

Make sure of that and then let us have a further communication.

[ckarail]

This is an internal firewall used to protect some servers in LAN. So, both of the inside and outside ports are in LAN. We are sniffing outside port through which the traffic flows from the clients/servers on some LAN VLANs to the servers behind firewall. That is why, we should be able to see on Capsa some TCP Repeated Connect diagnostics entries for the traffic which is dropped by firewall. We are already seeing on firewall logs that there are many drops on the Firewall. Because of this reason, we are evaluating if there is a bug on software about the interpretation of some diagnostic configurations.

[Nelson]

{QUOTE-> This is an internal firewall used to protect some servers in LAN. So, both of the inside and outside ports are in LAN. We are sniffing outside port through which the traffic flows from the clients/servers on some LAN VLANs to the servers behind firewall. That is why, we should be able to see on Capsa some TCP Repeated Connect diagnostics entries for the traffic which is dropped by firewall. We are already seeing on firewall logs that there are many drops on the Firewall. Because of this reason, we are evaluating if there is a bug on software about the interpretation of some diagnostic configurations. <-QUOTE}


Ok. Then the firewall must be a layer 3 forwarding device which not only have policies to restrict communication between hosts but also being in charge of connecting multiple subnet segements right?

So, there must be a conception like showing below:

VLAN1 -------------(link one)--------------- firwall ----------(link two)------------VLAN2

Try to monitor the logicl link one/two.
They might be interface vlan 1 or interface vlan 2, when you are doing a span. Use the SVI as source port.

If you can not see the "TCP repeated connect" in the diagnose View in neither link. Save the project files and send to us. I will check the packets manually.

The basic conception of sniffing techlonogy is that we believe the binary packets.
So:
If there are TCP repeated symptons there, it would be a bug of software.
If there are no TCP retry even in the decode binary frames, then it might be a misconception of sniffing.