Receive RST which is not found on the other side of the communication

asked 2019-01-09 09:58:52 +0000

BeatH
3 ●1 ●3

updated 2019-01-10 08:04:37 +0000

Hi
I have communication between a Linux and windows system. Don't have info about rooters/switches/firewall between.

The communication runs perfect, but out of the blue it send a RST. I trace both sides at the same time and try to understand why I receive a RST, which is not found in the trace file of the other side:

I receive on a Linux system [RST] Seq=xxx which is not in the trace of the windows system. Under Acknowledgment number yyy I have the ExpertInfo: The acknowledgment number filed is nonzero while the ACK flag is not set.

Would be great if somebody can give some advice how to proceed.

Thanks

Beat

Example

Everything is running normal
Then server-socket (Linux) sends client-socket (Windows) PSH, ACK <==is expected
8ms later client-socket (windows) sends RST --> server-socket (Linux)
This RST can be found only in the Linux trace. Not in the windows trace

edit retag flag offensive close merge delete

Comments

The easiest answer to the question "try to understand why I receive a RST" is "because an intermediate node inserts it". Since you have no information on any intermediate node this is what you should seek. Easiest starting point there is probably the Windows machine firewall, virus protection, etc, etc.

Also, try installing npcap to replace WinPcap for the Windows capture and see if that exposes something extra.

Jaap ( 2019-01-09 10:31:54 +0000 )edit

Hi Jaap I added an example. Do I understand you correct: A router/switch/firewall modifies messages? I would say this is spoofing.

BeatH ( 2019-01-10 08:07:19 +0000 )edit

Router or switch not so much, but firewall or IDS could modify/insert packets to reach their objective.

Jaap ( 2019-01-10 20:27:36 +0000 )edit

add a comment

answered 2019-01-15 20:26:40 +0000

SYN-bit

18528 ●9 ●343 ●255 https://SYN-b.it

On the Linux side, have a look at the value of IP TTL of the packets received from the Windows host. They are probably all the same. Now have a look at the value of the IP TTL of the received RST packet. Is the TTL the same or different? If it is different, there is a big chance that an intermediate device closed the connection. There can be several reasons:

The intermediate device is an IPS and saw data that triggered a rule to close the connection
The intermediate device is a firewall or loadbalancer that closed the connection due to a session timeout (what is the delta time between the RST and the previous packet in the TCP stream?

Comments

Hi SYN-bit

IP TTL is the same for PSH, ACK and the RST (127ms) I can find delta between previous PSH and RST from 1ms up to 3.5 secs. The application protocol allows a max of 10secs until an application line-check is send.

In the meantime we figured out that we had an ip-conflict. Since this is fixed. it seems to run. To learn something I filtered the conflict ip-address and checked the MAC in Ethernet II. But to my surprise they are all the same. So I'm still puzzled.

BeatH ( 2019-01-16 17:37:12 +0000 )edit

If the TTL of the packets from the windows system is TTL when they arrive at the linux system, then there was most likely 1 routing hop in between them. This means the mac-address of the windows host is stripped by that router and replaced with its own mac-address. So even when there are two different systems using the same IP address (with different MAC addresses), after being routed, their packets will have the IP and MAC address.

SYN-bit ( 2019-01-16 23:52:29 +0000 )edit

Thanks for the explanations. Now it makes sense.

BeatH ( 2019-01-17 07:32:55 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Receive RST which is not found on the other side of the communication

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Receive RST which is not found on the other side of the communication edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Receive RST which is not found on the other side of the communication