Share via

Windows 10 drops incoming TCP SYN packet for no reason

Anonymous
2020-02-28T09:13:27+00:00

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 NOTone of the following:

  1. Built-in firewall, which is the onlyfirewall 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 :(

Windows for home | Windows 10 | Internet and connectivity

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

14 answers

Sort by: Most helpful
  1. Anonymous
    2020-02-28T14:17:39+00:00

    Thank you for your detailed explanation. I am trying.

    0 comments No comments
  2. Anonymous
    2020-02-28T12:31:45+00:00

    Ok since you obviously did not understand what i meant i try to explain the working of this.

    Every packet has a time to life and a timestamp.

    TTL is how many jumps between diffrent hosts it can make until it deems itself undestinable and gets dropped on next jump.

    Timestamp tells any receiver of any package when it has been sent.

    So if you want to stop Windows from throwing away old packets it does nothing when you disable timestamps for outbound connections.

    The problem is that inbound packets get thrown for no reason but as i said i suspect that the linux server system time is out of sync with Windows time. The linux server signs the packet with its timestamp. Windows looks on it, sees its old, throws it away.

    Turn of the timestamp in your linux servers for outbound packages for tests.

    0 comments No comments
  3. Anonymous
    2020-02-28T11:28:19+00:00

    I tried this command netsh int tcp set global timestamps=disabledwith no luck*.* ;(

    Edit: netsh interface tcp set global autotuninglevel=disabled does not help neither.

    0 comments No comments
  4. Anonymous
    2020-02-28T11:21:51+00:00

    Thank you. I see the answers in that SF question. The system time of both parties are correct and they have the timezone settings.

    I have mentioned that some connections were not blocked. I mean, if timestamp is to be blamed, why it will only work for certain hosts? Anyway, I can try disabling timestamps first. Thank you.

    0 comments No comments
  5. Anonymous
    2020-02-28T10:53:28+00:00

    As already mentioned twice (by me and in the link i posted): turn of timestamps for the sending party for tests if you experience strange tcp syn disappearance or check the system time of both sender and receiver.

    0 comments No comments