Questions[rst](server)

Recently, my IIS 7.5 SSL site started refusing connections after a reboot. Oddly, the issue can be workaround by binding the site with a different cert and the switching back to the correct one.

When failing, wireshark shows the client send various SSL hello packets (TLS 1.0, 1.1, 1.2) and the server responds with a TCP RST. When working the client hello is virtually identical (same ciphers/compression/SNI.) Same behavior is displayed for IE and Chrome (contents are slightly different but instant RST is common) This indicates it is very likely something server side.

My only hint is random SChannel event ID 36870 "A fatal error occurred when attempting to access the SSL server credential private key. The error code reutrned from the cryptographic module is 0x8009030d. The internal error state is 1001." Checking my libraries 0x8009030d is "SEC_E_UNKNOWN_CREDENTIALS" and 1001 is likely MSG_FILE_NOT_FOUND.

Based on this I checked permissions on the Crypto/RSA folder per kb278381 and found them as expected. I forced inheritence on the underlying folders, but no change in behavior resulted.

Any clues on where to look next would be appreciated!

The tcp_rfc1337 setting seems to have a solution for TIME-WAIT Assassination.

The first problem is that old duplicate data may be accepted erroneously in new connections, leading to the sent data becoming corrupt.
The second problem is that connections may become desynchronized and get into an ACK loop because of old duplicate packets entering new connections, which will become desynchronized.
The third and last problem is that old duplicate packets may enter newly established connections erroneously and kill the new connection.

From what I read, to solve the problems, what the setting does is ignore the RST (reset) packets while the socket is in its TIME-WAIT state.

So, why isn't this setting enabled by default? What are the disadvantages of using this?

I actually learned about this variable when I was researching about stopping SYN flooding attacks. Do you think this setting helps with stopping them?

I 'm testing server stress test. server OS and client OS is CentOS6.4.

client try to 3000 connect, one connection send a one http request, by load test tool, weighttp. but, client get error. this error is connection reset by peer. I captured packets by wireshark.

0.523605     10.0.0.2 -> 10.0.0.1     TCP 74 45763 > ddi-tcp-1 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=178982970 TSecr=0 WS=128
0.533484     10.0.0.1 -> 10.0.0.2     TCP 74 ddi-tcp-1 > 45763 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=178914097 TSecr=178982970 WS=128
0.589445     10.0.0.2 -> 10.0.0.1     TCP 66 45763 > ddi-tcp-1 [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=178982993 TSecr=178914097
0.789282     10.0.0.2 -> 10.0.0.1     TCP 166 45763 > ddi-tcp-1 [PSH, ACK] Seq=1 Ack=1 Win=14720 Len=99 TSval=178983235 TSecr=178914097
0.839889     10.0.0.1 -> 10.0.0.2     TCP 66 ddi-tcp-1 > 45763 [ACK] Seq=1 Ack=100 Win=14592 Len=0 TSval=178914363 TSecr=17898323
0.845196     10.0.0.1 -> 10.0.0.2     TCP 303 ddi-tcp-1 > 45763 [PSH, ACK] Seq=1 Ack=100 Win=14592 Len=237 TSval=178914374 TSecr=178983235
0.845203     10.0.0.1 -> 10.0.0.2     TCP 678 ddi-tcp-1 > 45763 [PSH, ACK] Seq=238 Ack=100 Win=14592 Len=612 TSval=178914374 TSecr=178983235
1.071341     10.0.0.1 -> 10.0.0.2     TCP 915 [TCP Retransmission] ddi-tcp-1 > 45763 [PSH, ACK] Seq=1 Ack=100 Win=14592 Len=849 TSval=178914640 TSecr=178983235
1.076500     10.0.0.2 -> 10.0.0.1     TCP 66 45763 > ddi-tcp-1 [ACK] Seq=100 Ack=850 Win=16384 Len=0 TSval=178983531 TSecr=178914640
1.076575     10.0.0.2 -> 10.0.0.1     TCP 66 45763 > ddi-tcp-1 [FIN, ACK] Seq=100 Ack=850 Win=16384 Len=0 TSval=178983531 TSecr=178914640
1.076844     10.0.0.1 -> 10.0.0.2     TCP 66 ddi-tcp-1 > 45763 [FIN, ACK] Seq=850 Ack=101 Win=14592 Len=0 TSval=178914649 TSecr=178983531
1.337245     10.0.0.2 -> 10.0.0.1     TCP 66 45763 > ddi-tcp-1 [ACK] Seq=101 Ack=851 Win=16384 Len=0 TSval=178983535 TSecr=178914649
1.463888     10.0.0.1 -> 10.0.0.2     TCP 66 [TCP Retransmission] ddi-tcp-1 > 45763 [FIN, ACK] Seq=850 Ack=101 Win=14592 Len=0 TSval=178914911 TSecr=178983531
1.471462     10.0.0.2 -> 10.0.0.1     TCP 66 [TCP Dup ACK 9057#1] 45763 > ddi-tcp-1 [ACK] Seq=101 Ack=851 Win=16384 Len=0 TSval=178983923 TSecr=178914649
1.586270     10.0.0.1 -> 10.0.0.2     TCP 54 ddi-tcp-1 > 45763 [RST] Seq=851 Win=0 Len=0

I don't understand. Why server send RST packet to client after graceful close ?

I'm sorry for my bad English skill.

Thank you for replay.

I capturead packets on server side and client side. server is very delay.

server packets

  8.537458     10.0.0.2 -> 10.0.0.1     TCP 74 51446 > ddi-tcp-1 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=720269 TSecr=0 WS=128
  8.537461     10.0.0.1 -> 10.0.0.2     TCP 74 ddi-tcp-1 > 51446 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=691010 TSecr=720269 WS=128
 10.279094     10.0.0.2 -> 10.0.0.1     TCP 165 51446 > ddi-tcp-1 [PSH, ACK] Seq=1 Ack=1 Win=14720 Len=99 TSval=722038 TSecr=691010
 10.281834     10.0.0.1 -> 10.0.0.2     TCP 54 ddi-tcp-1 > 51446 [RST] Seq=1 Win=0 Len=0

client packets

  6.959709     10.0.0.2 -> 10.0.0.1     TCP 74 51446 > ddi-tcp-1 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=720269 TSecr=0 WS=128
  6.964438     10.0.0.1 -> 10.0.0.2     TCP 74 ddi-tcp-1 > 51446 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=691010 TSecr=720269 WS=128
  7.000836     10.0.0.2 -> 10.0.0.1     TCP 66 51446 > ddi-tcp-1 [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSval=720315 TSecr=691010
  7.002803     10.0.0.2 -> 10.0.0.1     TCP 165 51446 > ddi-tcp-1 [PSH, ACK] Seq=1 Ack=1 Win=14720 Len=99 TSval=720315 TSecr=691010
  7.222562     10.0.0.2 -> 10.0.0.1     TCP 165 [TCP Retransmission] 51446 > ddi-tcp-1 [PSH, ACK] Seq=1 Ack=1 Win=14720 Len=99 TSval=720562 TSecr=691010
  7.514462     10.0.0.1 -> 10.0.0.2     TCP 66 ddi-tcp-1 > 49507 [FIN, ACK] Seq=850 Ack=101 Win=14592 Len=0 TSval=691534 TSecr=720767
  7.703119     10.0.0.2 -> 10.0.0.1     TCP 165 [TCP Retransmission] 51446 > ddi-tcp-1 [PSH, ACK] Seq=1 Ack=1 Win=14720 Len=99 TSval=721054 TSecr=691010
  8.686885     10.0.0.2 -> 10.0.0.1     TCP 165 [TCP Retransmission] 51446 > ddi-tcp-1 [PSH, ACK] Seq=1 Ack=1 Win=14720 Len=99 TSval=722038 TSecr=691010
  8.709193     10.0.0.1 -> 10.0.0.2     TCP 60 ddi-tcp-1 > 51446 [RST] Seq=1 Win=0 Len=0

I checked os log (/var/log/messaeges), but, I couldn't find that server reached limits.

I am trying to resolve porblem. Thank you!

I've been fighting off a weird issue we've been having in our internal network: from time to time, multiple applications that we use simply freeze: SQL Management Studio, Red-Gate's Data Compare, Citrix GOTOMeeting and so forth.

I decided to get a trace of the network using Wireshark. I noticed just before things "froze", I found a MASSIVE number of RST packets being sent FROM our clients to the destinations, at the same time.

We're talking 37 RST packets at the same time (obviously milliseconds apart) to different destinations. Notice the RST packets are not being sent due to a failed 3-way handshake ... it is randomly being sent.

What could be the cause? What should I be trying to test? Thank you.

Well recently I've been reading about different Denial of Service methods. One method that kind of stuck out was SYN flooding. I'm a member of some not-so-nice forums, and someone was selling a python script that would DoS a server using SYN packets with a spoofed IP address.

However, if you sent a SYN packet to a server, with a spoofed IP address, the target server would return the SYN/ACK packet to the host that was spoofed. In which case, wouldn't the spoofed host return an RST packet, thus negating the 75 second long-wait, and ultimately failing in its attempt to DoS the server?

EDIT: And what if I'm not using SYN cookies?