IIS Based Application Load balancing Issue - F5
Hi Team, We are attempting to deploy an IIS Windows-based application on F5, but it is not functioning,we are receiving only the health check responses from LB to backend server, but not any actual requests from the load balancer. Could you please assist us with any necessary steps we need to follow while configuring F5 for an IIS Windows-based application? For your information, we have applied an SSL certificate on the backend server, but not on the load balancer. Could this be causing an issue? Additionally, it would be very helpful if you could share the recommended load balancing algorithm for IIS Windows. Thanks & Regards, Shivam Aggarwal
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.
