How to prevent Windows from sending RST packet when trying to connect to somebody via Pcap.net?

Question

I'm trying to use Pcap.Net to open a tcp connection.

I'm sending following package:

The server is responding with:

After this, Windows on its own sends the reset packet:

Why is this happening, and how do I block this behavior?

I'm doing this on Windows 7

Answer 1

As Mr Harris says, you can use WinDivert to do what you want. E.g. to just do the TCP handshake, you can write something like the following:

// TCP handshake using WinDivert:
HANDLE handle = DivertOpen("inbound && tcp.SrcPort == 80 && tcp.Syn && tcp.Ack", 0, 0, 0);
DivertSend(handle, synPacket, sizeof(synPacket), dstAddr, NULL);
...
DivertRecv(handle, synAckPacket, sizeof(synAckPacket), &srcAddr, &length);
...
DivertSend(handle, ackPacket, sizeof(ackPacket), dstAddr, NULL);
...

The DivertRecv() function redirects the server response into user space before it is handled by the Windows TCP/IP stack. So no pesky TCP RST will be generated. DivertSend() injects packets.

This is the main differences between WinDivert and WinPCAP. The latter is merely a packet sniffer, whereas the former can intercept/filter/block traffic.

WinDivert is written in C so you'd need to write your own .NET wrapper.

(usual disclosure: WinDivert is my project).

Answer 2

Either by using Boring Old Winsock to make a TCP connection to the server, rather than constructing your own TCP-over-IP-over-Ethernet packets and sending them to a server, or by somehow convincing the Windows Internet protocol stack to ignore the SYN+ACK (and all subsequent packets) you get from the server, so that it doesn't see the SYN+ACK from the server, notice that no process has tried to set up a TCP connection from 192.168.1.3:12456 to 192.168.1.1:80 using the standard in-kernel networking stack (i.e., nobody's tried to set it up using Boring Old Winsock), and send back an RST to tell the server that there's nobody listening at port 12456 on the machine.

You might be able to do the latter using WinDivert. It does not itself appear to have a .NET wrapper, so you might have to look for one if you're going to use .NET rather than Boring Old Unmanaged C or Boring Old Unmanaged C++.

Answer 3

Essentially, the problem is that scapy runs in user space, and the windows kernel will receive the SYN-ACK first. Your windows kernel will send a TCP RST because it won't have a socket open on the port number in question, before you have a chance to do anything with scapy.

The typical solution (in linux) is to firewall your kernel from receiving an RST packet on that TCP port (12456) while you are running the script... the problem is that I don't think Windows firewall allows you to be this granular (i.e. looking at TCP flags) for packet drops.

Perhaps the easiest solution is to do this under a linux VM and use iptables to implement the RST drops.