Intermittent Net::ERR_CONNECTION_RESET Error and Incomplete Loading over HTTPS
I have an F5 load balancing setup configured with two servers. My MVC web application, which incorporates Kendo UI, Jquery, and bootstrapping, is hosted on an IIS server with an SSL certificate. However, when accessing the application via HTTPS from outside the server, it often or sometimes results in a 'net::ERR_CONNECTION_RESET' error, with intermittent failures to load javascript and CSS files to the client browser. Strangely, upon reloading the page, the assets load properly, and the page functions as expected. This issue did not occur when the application was accessed via HTTP, where it worked properly without any issues. What could be the reason behind this problem?
stalled/blocked request
Hi, My short topology: client browser->F5->IIS servers I have a .Net web application. Randomly some request is in stalled/blocked state in browser. For example: I can see a request that spend 7 minutes in stalled state and then it is processed less than 1 second. I can't see high cpu, memory, connection load at this time. The peak connection is 4k, but I think it is not too high. At same time I can see lot of success request also. I think the request is waiting for something on my F5, but I don't know for what. Could anyone help me how can I detect the reason? My opinion is that I reached the connection limit but I can see any error message in log about it. How can I check it? Thanks.
CRM - Cross Domain Functionality Through F5
Hi, Our topology looks like this CRM_SERVER := internal.domain.com ^^ F5 := external.domain.com \ Azure plugin/SaaS service We are having issues where the external Azure plugin, in this case Click Dimensions, is raising an authentication exception when processing CRM data. We have the following iRule in place to handle header and payload rewrites. when HTTP_REQUEST { if { [HTTP::header host] eq "crmdev.external.com" } { HTTP::header replace Host "crmdev.internal.com" } Disable the stream filter for all requests STREAM::disable LTM does not uncompress response content, so if the server has compression enabled and it cannot be disabled on the server, we can prevent the server from sending a compressed response by removing the compression offerings from the client HTTP::header remove "Accept-Encoding" } when HTTP_RESPONSE { Rewrite the Location header replacing the internal hostname with the external hostname HTTP::header replace Location [string map -nocase {"crmdev.internal.com" "crmdev.external.com"} [HTTP::header Location]] only do this for text-based responses if { [HTTP::header Content-Type] contains "text" } { establish the stream expression STREAM::expression {@http://crmdev.internal@https://crmdev.external@ @https://crmdev.internal@https://crmdev.external@} STREAM::expression {@crmdev.internal@crmdev.external@} enable stream processing STREAM::enable } } As the F5 is in SSL offload mode, do we need to include anything to handle the HTTP 401 Challenge/Response to the IIS server? Or has anyone experienced similar issues where the F5 acts as the external face for applications on an internal domain?Can someone take a look and make sure I understand this right about reverse proxy
Preface: Yes I know not a whole lot but I'm trying. If someone could just take a look at this and maybe it will help me find what piece I am missing. We have an internal server that needs to be accessed on the outside, but they don't want it actually touching the internet so we run it through the BIG-IP F5 LTM. The internal IIS has an internal IP and an external IP assigned. The DNS entry is bound to the External IP address. A lot of what I setup has been copied from a currently working site that utilizes this exact same process. From my understanding the connection "route" is as follows: Internet-->ExtIP-->F5virtualIP-->IntIP The External IP gets natted on the firewall to the F5 internal IP of the virtual server, and then the F5 virtual server is linked to the actual internal server IP. We have access rules in place to allow public access to the external IP as well as the F5 IP. There are NAT rules in place that *should* point anyone going to the external IP towards the F5 address, and then through that to the internal server. There's an F5 rule in place that redirects from http to https as well. Internally, on my work PC, I can navigate to the site via it's FQDN. Externally though, I get a Not Secure Site message(we haven't gotten the cert in place yet so that is expected), but then after a while of trying to load, we receive an ERR_CONNECTION_RESET page and it can't load. I feel like there is something I am missing but I just can't think of what it is. If anyone has any ideas I will be eternally grateful. Thank you in advance.
IIS 6.0 WebDAV Buffer Overflow
Today we are reminded that old software can include new and critical security findings. Microsoft IIS 6.0 on Windows Server 2003 R2 is vulnerable to buffer overflow which leads to remote code execution. This is due to inproper validation of the If: header which is used in WebDAV. This issue is covered by CVE-2017-7269. The vulnerability is exploited by sending a malicious PROPFIND method to the vulnerable server. By default, this method is disabled on ASM. However, it is crucial for the proper function of WebDAV, so policies which protect this kind of application have probably enabled it. IIS 6.0 Despite being a 15 year old product which is not officially supported by Microsoft anymore - The web still uses IIS 6.0 in very large numbers. A search in Shodan shows that over 600k servers are still live: https://www.shodan.io/search?query=iis+6.0 Mitigation with attack signatures ASM users are encouraged to use the following attack signature to detect exploitation attempts for this vulnerability: content:"PROPFIND"; depth:8; headercontent:"If: <http://"; pcre:"/^If: <http:\/\/[^>]*?[\x80-\xFF]{5}/Hm"; This signature is due to be included in the next ASU, being released early April.
IIS X-Forward-For ISAPI Filter
A recent customer issue came up where they were load balancing servers but we unable to get the true client address logged in their IIS logs. They had their servers fronted by a BIG-IP and when clients would make requests the address passed to the server was the internal address and not that of the client. This is a common issue with proxies and fortunately there is a standard for forwarding client information. It is the HTTP X-Forwarded-For header which is handled by most proxies. So, I set out to find an existing ISAPI filter to replace the c-ip (client ip) log value in IIS with the contents of the X-Forwarded-For header (if it exists). I was amazed to find that I couldn't find a single instance of any open source (or even commercial) filter that would do this. So, I dug out Visual Studio and whipped up a filter that does just that. It's very basic and contains no user configuration so all you need to do is plug it into your Web Applications list of ISAPI Filters within the IIS Administration and you're set to go. We've released the source under the iControl End User License Agreement (available in any iControl SDK download). You can download it here. If you find a way to optimize this filter, please let me know and I'll update the sources here. After 24-hours of posting, a customer already returned some performance testing on the filter indicating that it only effected the traffic by less than 1 percent. I'm sure there are ways to optimize the memory allocation in the filter to speed this up a bit more, but I'll leave that for the community to work on. Oh, and it should be noted that the X-Forwarded-For header isn't supported the same way across all proxy products so you'll want to make sure you test this out before using it. It is expecting the header to only contain an IP Address as it does a straight substitution on the value in the c-ip section of the log entry. Enjoy! -Joe
