[SOLVED more or less] pfSense closing IIS HTTP connection on Response.Flush?



  • On my internal network I have a Windows 2012R2/IIS 8.5 webserver running a Classic ASP website.

    Until yesterday I was using an old WRT54G router that forwarded my external IP address to this webserver. This has been running for years.

    Yesterday I switched to pfSense (the latest v2.3.2) and setup a NAT rule to the server. At first everything seemed to be ok until I found out a few (but always the same) pages never finished loading (my browser kept saying 'Loading').

    After some detective work I found out that (only) the failing pages had a 'Response.Flush()' statement. With that knowledge I could reproduce the problem with the following test.asp file:

    
    <%@language = "javascript" %>
    <%
      Response.Write("Hello ");
      Response.Flush();
      Response.Write(" World");
      Response.End();
    %>
    

    When this page is accessed from the outside world through pfSense it never finishes loading. When accessed internally directly to the server it works fine.
    When I remove the Response.Flush(); line it works fine with pfSense as well.

    This may be relevant: the Fiddler statistics for a failing page suggest a ServerDoneResponse was never passed through pfSense:

    ServerConnected:	12:39:38.938
    FiddlerBeginRequest:	12:40:00.801
    ServerGotRequest:	12:40:00.801
    ServerBeginResponse:	12:40:00.806
    GotResponseHeaders:	12:40:00.806
    ServerDoneResponse:	00:00:00.000
    ClientBeginResponse:	00:00:00.000
    ClientDoneResponse:	00:00:00.000
    

    This may very well be an IIS quirk but as there is only a problem with pfSense and not without it I was hoping someone might understand what is going on.



  • After some more investigating I think I found the 'cause'. Under System/Advanced I had 'NAT + Proxy' configured for NAT reflection.

    After I replaced it with split DNS (forwarded internal traffic directly to the webserver) all problems where gone.

    I still think it is strange (and perhaps a bug) that with NAT+Proxy a Response.Flush by a webserver can cause failure but if I understand correctly NAT reflection is always a bit of a hack.


  • Rebel Alliance Developer Netgate

    NAT Reflection is definitely a kludge but, sadly, it still has a place in some setups

    Order of preference is:

    1. No reflection / Split DNS (Best)
    2. Pure NAT reflection (OK)
    3. NAT+Proxy (Bleh)


Log in to reply