Windows 10: Windows 10 drops incoming TCP SYN packet for no reason

I am running some services on my Windows 10 laptop behind a NAT server I have set port forwarding rules. I am encountering the issue that Windows drops incoming TCP SYN packet from some IP addresses for no reason. To be specific, currently, only the laptop itself and connected via SSH remote servers are whitelisted by some unknown firewall-like thing. According to my examination, the reason seems to be NOT one of the following:​

​

1. Built-in firewall, which is the only firewall on my system, is blocking incoming connection because I have whitelisted all the services/applications, and even if I turn off the firewall, nothing is changed
2. The upstream is blocking incoming connection because the RaspberryPi under the same network does not have the same issue

What's more, I can confirm that the link is not broken because I did see the initial SYN packet and some retransmitted SYN packet of the incoming connection in Wireshark. However, I did not see any SYN-ACK packet in response to those SYN packets in all network interfaces. It seems like the connection event did not reach the application layer.​

​

Things got even more weirder after last time I booted into safe mode to see if the issue remains unresolved. The issue did remain unresolved in safe mode, so I rebooted the system without any changes to firewall rules or anything. Magically, after this reboot, the problem disappeared for no reason. Everything was working great since then, until I rebooted, again. Now Windows I assume that it is Windows is again blocking incoming TCP connections.​

​

Can anyone help? Really sad :​

:)

 

3 Second Delay in TCP SYN for the IPSec in Windows 10 compared with Windows 7

Hi,

I am facing a strange issue with the TCP connection in Windows 10 compared with Windows 7. I am observing a delay of 3 seconds while establishing an IPSec connection in Windows 10, while in Windows 7, the connection is established in milliseconds. I was
surprised to see that the changing the InitialRTO from 3 seconds to 1 second reduced the connection establishment time from 3 seonds to 1 second in Windows 10. Obviously Windows 7 is not having InitalRTO TCP parameter and I am not sure how much is the default
being set in Windows 7. So, my issues is, the extra delay in Windows 10 is causing problems in existing scripts and need the reason for the delay being introduced in the Windows 10.



A detailed step by step problem statement is provided below;

· I am testing scenario using SIP (Session Initiation Protocol) server and SIP client. SIP server always running on Windows 7, while SIP Client need to be upgraded from Windows 7 to Windows 10.

· The first TCP connection between SIP client to SIP server is established (3 way SYN handshake)

· SIP Client sends REGISTER message with IPSec requirement to SIP server.

· SIP server responds with “401 Unauthorized” with server details for establishing an IPSec connection

· SIP client tries establish a new IPSec connection with SIP Server

o My code calls the
connect immediately after getting the Server Response, with new connection details.

o The first Encrypted packet SYN to server is sent by the Windows only after 3 Seconds in Windows 10, while the same SYN is sent out within few milliseconds in Windows 7.

o Changing InitialRTO from 3 Seconds to 1 second will help Windows 10 to send the encrypted SYN faster.

I would like to know why this delay is introduced in Windows 10? Why changing the Initial RTO from 3 Seconds to 1 Second, changes the time required to send a SYN?



Even though the RFC 6298 asks to change the Intial RTO to 1 second from the old 3 seconds, why Windows 10 is keeping the same in 3 seconds.



Thanks

Susanth

see the packets 3045, 3046 and 3078

 

Simulate SYN attack

I apologize in advance if I don't truly understand the question.
When sending a SYN flood attack the point of it to attempt to create as many half open connections on the victim as possible. This leaves each of the half open connections in the SYN-RECVD state temporarily utilizing resources.

However, it appears that you are not sending your SYN flood properly by not spoofing the attackers source IP. When your attacking machine receives the SYN/ACK it will immediately send a reset packet shutting down that socket and negating any flood attempts. However I am not familiar wit the behavior of the Windows Firewall. If you spoof the source address to an unused IP the RST will not get sent and each SYN/ACK being sent by the victim will go into exponential back off dramatically upping the effectiveness of the attack. (please use an IP in private space so the SYN/ACKs aren't reflecting back at something on the internet)

Ok, next up is the fact that you are replaying the same packet with the same 4-tuple and the same initial sequence number. You need each SYN to be unique to be effective. I would strongly suggest you use any Linux distro and the application "hping3". You should be able to get the results you want. Also consider that ping uses ICMP and may not be a good test of server delay since it is considerably different process in how the server responds. May I suggest nmap or even hping3 again for testing the servers TCP response.

 

TCP connect fails with certain websites

I am running Windows 10. I am unable to browse a few seemingly random websites (CBS.com is one of them) using any of my browsers, although I can successfully ping all of them. Also, other computers on the network do not have the same problem, and my computer does not have this problem on other Wi-Fi connections. The same connection time out error occurs when I use the IP address instead of the website name.

Using wireshark, if I go to a working website, I see a TCP [SYN] sent by me, a [SYN, ACK] sent back and a final TCP [ACK] before I send a HTTP GET request.

However, when I attempt to load the non working sites, using either the URL or IP address on different browsers, or Curl, the following happens:

1. After the initial TCP [SYN] packet, I receive at TCP [SYN, ACK]
   packet with a [ETHERNET FRAME CHECK SEQUENCE INCORRECT] error.
   
2. I send a second TCP [SYN] with the same result.
   
3. Then I send a few [TCP Spurious Retransmission] packets, with each one being followed by a receipt of a [TCP Retransmission] with the same [ETHERNET FRAME CHECK SEQUENCE INCORRECT] error.
   
4. The above all happens again, and then the request times out and connection attempts stop.
   

Does anyone have any advice for solving or troubleshooting? I haven't been able to find anything online.