2

I have recently been trying to track down a problem with one of our systems and have noticed that it is simply not allowed to connect to a remote machine.

However, the remote machine (not controlled by us) is responding to our request for a connection with many TCP RST packets on a different port (26469, 26497, 26498) than the one we originated on (53).

It simply wouldn't let up at one point and flooded us with about 10 packets/second for an hour or two of only RST on those obscure high ports.

Out of the thousands of nodes we're connecting to, this is the only one ever to show this behavior. What could possibly cause this?

EDIT

Below is a screenshot of Wireshark when it happened. I don't have the actual dump anymore and can't reproduce this specific scenario every time. Basically, we sent a SYN and immediately got RST on an odd port and so we respond with RST and just keep going back and forth. RST Spam

4
  • Could you supply a tcpdump? Nov 4, 2012 at 15:11
  • @AlexanderJanssen Close to, but not quite. Edited the original post for you. Nov 4, 2012 at 15:16
  • So your TCP-connections really originate from TCP 192.168.0.10:53 and you got to that host on tcp/80? I find this mildy odd, but however, that trace above shows normal behaviour. But since this in not the real scenario, I want to ask if you do the same to the real host. You come from 53 and go to 80, but you get RST/ACK from totally differnt ports form the remote host? Nov 4, 2012 at 15:22
  • @AlexanderJanssen It's just RST and the varying ports were due to not reading the output an additional time. But, still there should be a RST-ACK coming back and not just RST! Nov 4, 2012 at 16:07

1 Answer 1

2

What I see here is that 192.168.0.10 is attempting to open HTTP connections to 139.179.55.181, and these connections are being refused.

The high port numbers that you're seeing originate as the source port numbers for the connections from 192.168.0.10. The RST segments are getting sent back to the exact same port numbers that the SYN segments came from. This is how TCP is supposed to work.

4
  • Actually, no HTTP is being done. It's a different protocol, but on port 80. Anyway, the odd part is that those source port numbers are not 80. When you connect to a host from port A to port B, they should respond from port B to port A. So in this case, I request a connection from 53 on 80 and they should respond with packets from 80 on 53, no? Additionally, it's standard for an active refusal to be done with a RST-ACK packet, not just a RST packet. Nov 4, 2012 at 16:03
  • I also just realized that I requested a connection from 53 to 80 and then it refused it with RST and then the machine for some reason responded with RST from a different source port and caused all of that confusion. My mistake for not reading it three times :) Nov 4, 2012 at 16:05
  • @Michael J. Gray: When you make an outgoing TCP connection, your OS TCP stack usually will pick a random source port to receive the response packets. While you always have to pick the destination port number, it's highly unusual for you to pick your own source port number when making TCP connection. That's just how TCP works.
    – Lie Ryan
    Dec 23, 2021 at 15:34
  • A TCP connection is identified by four-tuple: (Source IP, Source port, Destination IP, Destination Port). Randomising the source port number allows every parties involved in transmitting a TCP packet to distinguish between multiple TCP connections between two machines.
    – Lie Ryan
    Dec 23, 2021 at 16:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .