 | 1 | initial version |
From your description one can deduct that there is an intermediate device generating the RST impersonating PBX B. This can be concluded by the fact that you don't see this packet in the trace at PBX B and also because the IP TTL is different. You can look at the ip.id of packets from B and if they slowly increase and the ip.id of the RST is way off, that's another indicator for it being sourced by a different system.
As for the ACK bit, this bit is set when the system sending the packet took care of generating a proper ACK value. The ACK bit set means "ACK field is relevant".
Was there an idle time in the connection before the RST from B to A was generated? In that case it might be a session based device that hit an idle timer. If so, you can either find that device and change the idle timer for the protols that are used between PBX A and PBX B. Or you can use a Keep-Alive mechanism, either at the TCP level or at the Application level.
If there was no idle periode before the RST, was there a packet being sent by PBX A just before receiving the RST? If so, it might be an IDS or IPS that has a (false) positive on it's detection rules and it was configured to actively close the connection on this detection. In that case, find the IDS/IPS and check/update the detection policy.
In either case, it would be interesting to know which system was responsible for sending the RST and it should not be difficult to find as the TTL is 254 which means it can only be one hop away (unless you have some MPLS or other tunneling in place, then of course it could be on the other side of the link).
