This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Windows sends RST after SYN-ACK on a TCP connection

0

I'm developing an Windows application that performs NAT between a virtual TAP interface and a physical Ethernet interface (with the purpose of achieving load balancing), using WinPcap. The test setup looks something like this:

alt text

I ran the test on two machines with Windows 7 64-bit, and on one of them everything works as expected, but on the other one, after SYN-ACK is received Windows sends a RST, and I don't understand why.

Here is a Wireshark capture file recorded on the physical interface. The test consist in running a web browser and try access a website. Because the default gateway is set on the TAP interface, all traffic goes through it. So this is what happens:

  • SYN is received on TAP interface
  • my NAT application performs NAT on the packet and sends it on physical interface
  • a SYN-ACK reply is received on the physical if
  • for some reason Windows replies with a RST on the physical if
  • in the meanwhile my app performs NAT no the SYN-ACK packet and sends it on TAP
  • unaware that a RST was sent on physical if, Windows sends an ACK on TAP
  • and from here on the website replies with a RST because physical if broke the TCP connection

Initially I thought that the Windows firewall might be the one breaking the connection, but the problem doesn't go away even if I disable the firewall. Besides, I installed the same firewall on the machine that didn't have problems before and it stayed that way, everything worked as expected.

Who is sending that RST on the physical interface? How could I find out?

asked 01 Feb '14, 07:40

Chris%20DB's gravatar image

Chris DB
16114
accept rate: 0%


One Answer:

1

The usual reason for a Reset being sent is either that the incoming packets were in some way catastrophically bad/damaged (which doesn't seem to be the case here), or that the application holding the port has released it in the meantime. That results in the stack receiving a packet for a closed port and answering with a reset.

You could monitor your port state table (via netstat or Sysinternals tools like TCPView and Process Viewer) to check if your application is closing the port. Microsoft NetMon can also help with that I guess, but I don't have much experience with it.

If this would be my application I'd try to add debug messages for the component that opens and closes the ports to see when that happens, and add additional exception handlers to see if errors are thrown that could explain the socket closing.

answered 01 Feb '14, 08:01

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

The port is not closed. The port is held by the web browser (Chrome), and you can see that after the RST, Chrome still sends an ACK and a HTTP-GET. I had no idea that the stack is supposed to respond with a RST if it receives a packet for a closed port. Are sockets tied to an interface or do they listen on all interfaces ?

(01 Feb '14, 08:17) Chris DB

Yes, there is an ACK and a HTTP-GET but I guessed that this is from a different process using the same port. It's a little hard to say why that happens, because when a stack sends a Reset it should not reuse to port for anything else for a while. So how come that Chrome is on that port? I thought that trace contains what your NAT application is doing? Or is you application running inside Chrome?

Sockets can be tied to one or multiple interfaces. You can see how it is bound by using "netstat -an" - if the listening IP is 0.0.0.0 the port is open on all interfaces; if there is a specific IP it is only open for that IP.

(01 Feb '14, 08:26) Jasper ♦♦

BTW, I wrote a program once that showed the exact same pattern: SYN - SYN/ACK - RST. The reason was that I had misinterpreted the socket timeout settings - I thought the value I put in that parameter is seconds, so I used "10", but it was "microseconds". Which meant that when the SYN/ACK came back from the server my client had already torn down the socket again, because it took the server longer than 10 microseconds to respond.

(01 Feb '14, 08:31) Jasper ♦♦

The NAT app is using WinPcap, so it's capturing the packets from one interfaces, modifies the MAC/IP addresses accordingly and sends it on another interface, without port translation. My app doesn't work with sockets, they are handled by the requesting app (i.e. Chrome). Packets are captured by the WinPcap NPF driver at a very low level (before tcpip.sys) and ideally, the stack on the physical interface should ignore the packets and not respond. But it looks like that doesn't happened. I guess there is no escape, I have to do port translation ...

(01 Feb '14, 08:45) Chris DB

Okay, that is your problem then - you're basically listening passively for packets that the host does not have a socket for and so it refuses the connection. You have to do port translation, yes.

(01 Feb '14, 09:09) Jasper ♦♦