IIS 6 / 2008 R2 Server Sending Resets RRS feed

  • Question

  • User-1079866723 posted

    This afternoon, one of our servers running 2008 R2 and IIS 6 started sending resets.  We were first alerted to the problem by a monitoring service that told us the connection was refused.  I dug into IIS and Windows Firewall logs and found that when the connection worked, IIS and the firewall both logged it as expected.  When the connection didn't work, neither of them logged it.

    I logged into our hardware firewall/router and noticed the dropped connections were seen there, and were listed as being reset by the server.  I ran a packet capture on the IIS server and I was able to confirm that the packet comes in, and is immediately responded to with a reset most of the time.

    I can find no logging as to why this might be the case.  We tried reverting the server to a backup from the previous day (when there were no issues), running on a separate physical host, and the issue persisted.

    Any ideas?  I'm not sure what logs I would be able to look at since the reset happens immediately.  I don't think the firewall or IIS ever see the packet.


    Monday, November 5, 2018 3:26 AM

All replies

  • User-1079866723 posted



    Monday, November 5, 2018 3:29 AM
  • Monday, November 5, 2018 7:32 PM
  • User-1079866723 posted

    Thanks for the reply.  The HTTP error logs don't show anything relating to that traffic during the time of the issue (or ever), unfortunately.

    The problem stopped on its own overnight.  The last thing I did was use IIS Crypto and completely redo the settings for protocols and cyphers.  Typically we run the best practices template, but I noticed the server had some extra items enabled compared to our reference list (nothing disabled that shouldn't have been, however).  I loaded defaults, then manually enabled/disabled and ordered everything through IIS Crypto, then rebooted.

    The problem still persisted after this for about an hour.  Then it stopped with no further changes made.  I do notice FAR fewer Schannel errors in the event viewer now than during the issue.

    I'm still looking into the cause, in case it happens again or happens elsewhere.

    Monday, November 5, 2018 8:04 PM
  • User-72702933 posted

    Hi bw_bloodletter,

    Could you please tell me which connection dropped? Tcp?

    Do you mean you hosted web application which use TCP access another resources dropped?

    Best Regards,


    Wednesday, November 7, 2018 9:04 AM
  • User-1079866723 posted

    It's a webserver.  IIS.

    We have an external service that does an HTTP GET for a domain and expects some sort of HTTP response.  If it doesn't get that response, the external service sends us alerts.

    We started getting alerts and couldn't figure out the cause.  I did a packet capture, as shown in the screenshots I included, and you can see that the incoming TCP connection.  When we were having the issue, our server was immediately responding to the incoming TCP connection with a packet that included the reset flag.  Normally, our server should respond with a packet containing syn & ack, then the external server responds with ack and then the HTTP GET request, which our server fulfills, before the connection is closed.

    I still have no clue why our server was resetting those connection attempts when we had the issue.

    Thursday, November 8, 2018 7:23 PM
  • User-72702933 posted

    Hi bw_bloodletter,

    According to your description and image, I found your server directly sending resets and not handle this connection in the IIS.

    Do you enable any setting in the server that will monitor the traffic?

    It seems your server not handle these connection not iis.

    Best Regards,


    Wednesday, November 14, 2018 6:36 AM
  • User-1079866723 posted

    No, there's nothing that I'm aware of that's monitoring and blocking/resetting the connection on port 80, unless there's something that does it by default in Server 2008 R2 that I don't know about.

    And as you can see, sometimes it was reset, sometimes it was allowed through, even though the source and content are the same.

    Wednesday, November 14, 2018 5:14 PM