We have two Windows 2008 R2 serveres set up with a Cisco Ace-30 load balancer, and a few MVC and WebForms apps (.net 4.5 and 4.5.1) with federated authentication (thinktecture). The load balancer is configured with ssl, but the traffic from load balancer to web servers is on http. The problem I'm trying to solve is that the part of the url is case sensitive. Take this urls:
https://my-server.temp.net/MyApp/ (working)
https://my-SERVER.temp.net/MyApp/ (working)
https://my-SERVER.temp.net/MyApp/DEfault.AsPX (working)
https://my-server.temp.net/myapp/ (not-working, that is no response)
In the load balancer, I've disabled the default case sensitivity, and from what I've read there's no such setting in IIS. I've tried creating a static website (no auth) and this works as expected:
https://my-server.temp.net/StaticSITE/ (working)
https://my-server.temp.net/staticsite/ (working)
I've also tried setting up a url rewrite rule, and once that rule is applied the the timeout appear. My guess is that it is IIS that rewrites the incomming http request to a new http request, and the load balancer does not recognize its the https request that has been modified. But I'm guessing and beyond my comfort zone here.
So now I'm a bit confused and unsure what's causing the url to be case sensitive. Is it:
The load balancer
IIS
The authentication
Something else
I would be really happy for any ideas or debugging tips
Thanks
Larsi
ok, I figured out the problem (or atleast a solution). The IIS was sending a redirect and that redirect was to a http address.
So when we configured the load balancer to redirect http to https everything works as expected. My guess is that the federation was causing the IIS to do an extra redirect when the casing was not correct, but that's just a thought.
Anyway - http to https redirect on load balancer solved it.
Larsi
Related
I have a few websites that use to be on a server using iis7 as the host. I have moved these websites to a new server that is IIS8 and the database has been upgraded from SQL 2005 to SQL 2014.
Another part of this change is it now runs through a DMZ reverse proxy that redirects to an internal server.
This works fine in Chrome or Edge. But Firefox and IE I get a 500 URL Rewrite Module Error. Not much more information in the error other than that.
I have other sites on the reverse proxy that work with no issue. But all of the ones that work are .net 4.0 or higher. The sites I am having issue with are both 3.5 framework.
I have tried setting the app pool framework on the dmz to match the internal server.
There are currently 2 inbound rules one converts http to https and the other is the proxy rule. There is 1 Outbound rule which is also part of the revers proxy. The reverse proxy currently takes the https traffic and uses http internally and then the outbound sends it back as https. This is that same on all of the site on this server that currently work without any issues.
Some more information. I turned of error tracing and the fuller error I received is
Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded ("gzip").
This is because the responses that are coming from the back end server are using HTTP Compression, and URL rewrite cannot modify a response that is already compressed. This causes a processing error for the outbound rule resulting in the 500.52 status code.
There are two ways to work around this: either you turn off compression on the backend server that is delivering the HTTP responses (which may or may not be possible, depending on your configuration), or we attempt to indicate to the backend server the client does not accept compressed responses by removing the header when the request comes into the IIS reverse proxy and by placing it back when the response leaves the IIS server
There are a number of step needed to complete this fix you can find them and all the information you need at https://blogs.msdn.microsoft.com/friis/2016/08/25/iis-with-url-rewrite-as-a-reverse-proxy-part-2-dealing-with-500-52-status-codes/
It is a 3 part post and the second post in the series was the solution.
How can I make IIS and ASP.NET aware of SSL Offloading so that it uses correct protocol for Response.Redirect?
I am working with a client who is using F5 load balancer with SSL offloading. The IIS web site (and ASP.NET web app) are bound to HTTP, not HTTPS, and so whenever ASP.NET uses Response.Redirect(url) it results in 302 redirect to http instead of https
Obvious solution would be to bind to HTTPS in IIS, but client does not operate that way. They have numerous other applications (mostly on apache) and report that it works just fine (it is somehow aware of SSL Offloading). SSL terminates at the load balancer, meaning user-to-load balancer is HTTPS, and then load balancer-to-server is HTTP. And they want to keep it that way (makes it easier for IDS to detect attacks in encrypted payloads, IT can snoop on users, etc.).
We've tried URL Rewrite module (from Microsoft) with very limited success. Client's IT dept reports they have also tried some configuration with F5 but I am not familiar with this product and apparently neither are they. It would be much easier if we could just force a flag in IIS or something, but I have been looking over Msft docs with no answer found so far.
Looking for a solution that is applied only to IIS, please. Thanks!
I am having a problem with an old school asp.net site that has been moved behind a SSL terminated loadbalancer. All traffic to IIS is coming from the load balancer as port 80 http traffic. IIS is rendering all the script/image/link urls into http://....
The problem for us is the client browers are seeing pages with absolute URLs containing http protocol links within a https:// page. The browsers are warning about mixing secure and insecure content.
How can this be fixed so that the links are generated with https:// instead of http://
Thanks in Advance
bille
We solved our issue. The problem turned out to be the load balancer configuration. The client is very compartmentalized and denied us access to the LB swearing that the config was correct. After proving to them that telnetting into 443 was being blocked for some stuff we were allowed access to the LB. In addition to just being set up wrong (cut and paste) the LB url rewrite rules were messed up. Fixing those all is good.
I have an IIS6 ASP.NET 2/3.5 site that ALWAYS seems to be caching anything that goes through a https request. HTTP requests always work the same, but i see old/invalid data on https requests.
I see this a lot with pages where i'm doing http rewriting--but in general, it almost seems like the site has one set of values it shows to http requests and another to https requests-- without having any backend code that renders differently based upon the scheme.
Any ideas? Does IIS have a weird ssl caching option i'm not aware of?
The ports were set up wrong in IIS-- although the domain was correct because i was using port 443 it got forwarded to another site (because of host headers setup).
I have a web server running Windows Server 2008 with IIS7. I have a bunch of websites which are all bound to the same IP address, but with different host header values. Most of the host headers are something like www.sitename.com.
I also have a corresponding website entry for each which listens for the host "sitename.com" and does a redirect to "www.sitename.com" within IIS7 (to cater for non-www requests). Now this is all pretty straight forward, but I've noticed the when setting up the Http Redirection, some wierd things happen:
Firstly, the "redirect" website entries must be pointed at a different physical directory than the site it's trying to redirect to, otherwise the redirection settings get set for both sites at once.
Secondly, sometimes whilst setting up Http Redirection on an individual site, Http Redirection gets set at a server level, and all sites start redirecting to that one URL.
How does this happen? Under what circumstances could setting Http Redirection on an individual site affect all sites? This is scary!!!
You need to point each of the websites to different physical location so that Http Redirection module can make a webconfig file for each of them.