How to prevent Windows from sending an RST packet when trying to connect to someone through Pcap.net?

Question

I am trying to use Pcap.Net to open a tcp connection.

I am sending the following package:

The server responds:

After that, Windows itself sends a reset packet:

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

I do it on windows 7

Answer 1

As Mr. Harris says, you can use WinDivert to do what you want. For instance. to just do a TCP handshake, you can write something like this:

// 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 to user space before it is processed by the Windows TCP / IP stack. Thus, TCP RST does not bother. DivertSend () injects packets.

These are the main differences between WinDivert and WinPCAP. The latter is just a packet sniffer, while the former can intercept / filter / block traffic.

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

(regular disclosure: WinDivert is my project).

Answer 2

Essentially, the problem is that scapy runs in user space, and the Windows kernel will first receive the SYN-ACK. Your Windows kernel will send TCP RST because it will not have an open socket on the specified port number before you can do anything with scapy.

A typical solution (on Linux) is your kernel firewall from receiving the RST packet on this TCP port (12456) when you use the script ... the problem is that I don’t think the Windows firewall allows you to be so granular (t .e. look at the TCP flags) for packet drops.

Perhaps the simplest solution is to do this using the Linux virtual machine and use iptables to implement RST drops.

Answer 3

Either using Boring Old Winsock to make a TCP connection to the server, rather than creating your own TCP-over-IP-over-Ethernet packets and sending them to the server or somehow convincing the Windows Internet protocol stack to ignore SYN + ACK (and all subsequent packets) that you receive from the server so that it does not see SYN + ACK from the server, note that no process has tried to configure a TCP connection from 192.168.1.3:12456 to 192.168.1.1:80 using the standard intranuclear network stack (i.e. no one tried to configure it using Boring Old Winsock) and send RST to tell to the doorway that no one is listening in port 12456 by car.

You may be able to do the latter using WinDivert . It doesn't seem to have a .NET wrapper, so you might have to look for it if you are going to use .NET rather than the boring old unmanaged C or the boring old unmanaged C ++.