I am publishing a web farm and everything is working except for one annoying little thing. I am forwarding all port 80 traffic to https in the publishing rule but when it forwards http://www.foo.com/page.htm, it forwards to https://www.foo.com:0/page.htm. I'm not sure why that ":0" gets in there and it works fine in IE but a firefox user that tries to go to http gets an "Unable to connect" error and has to manually remove the ":0" to get to the page.
Looking in the logs I see the client connecting to ISA but not getting redirected to a web server in the farm. ISA sees them trying on port 80, says there was a failed connection attempt, and gives me an http status code of 12241. I can't find the definition of that status code anywhere.
Whoa! Why would you forward HTTP as HTTPS? Isn't that a waste of resouces? The client to ISA Firewall should be SSL and the ISA Firewall to Web server should be SSL for secure end to end security.
So I would think that this would direct the client to forward to the https site. Not just forward from isa to the web server in https. Actually I am pretty sure that it is doing a simple client-side redirect because otherwise I wouldn't see https on the client if ISA were doing all of the work.
I just re-read my original post and can see what happened. Bad description of the setup on my part. Sorry about that. I think my last post clarifies things and should be a "safe" solution. So - any solutions to the problem I am seeing?
So I would think that this would direct the client to forward to the https site. Not just forward from isa to the web server in https. Actually I am pretty sure that it is doing a simple client-side redirect because otherwise I wouldn't see https on the client if ISA were doing all of the work.
Am I missing something here?
Thanks, Calvin
Hi Calvin,
OH! OK, that makes sense. Yes, you can configure the ISA Firewall to redirect HTTP to HTTPS and is being working pretty well.
I just re-read my original post and can see what happened. Bad description of the setup on my part. Sorry about that. I think my last post clarifies things and should be a "safe" solution. So - any solutions to the problem I am seeing?
Hi Calvin,
Have you tried it with IE 7? Since IE 7 makes IE more secure than Firefox, it makes sense to go back to it.
Yeah I have tried IE7. It is smart enough to ignore the ":0" part of the address and it brings me to the site. But I can't really control the client the users will use. Any idea why that is getting put in the url and more importantly how to get rid of it?
I should note that I am using this same rule when publishing 2 single web servers and it works fine. I have created 2 new web farm publishing rules as we are deploying a new web farm to replace the previously mentioned servers and both of the web farm publishing rules behave the same way (appending the :0) but both of the single web server publishing rules don't. So it appears this is a web farm specific issue.
Now when you talk about checking packet traces...do you want anything from me or is this something you can reproduce and test on your end?
I finally got this fixed. Turns out it is related to a bug in the Link Translation module. I'm not 100% sure how that plays in since I am actually using the redirection option but it must use something from link translation to redirect the user. There is a hotfix #927265 that fixes the problem. If anyone else is seeing this though, that hotfix is not released publicly yet so you have to contact Microsoft support to get the download.
Thanks for the help...hopefully this helps someone else.
I am also getting this :0 error at the end of a redirected HTTP to HTTPS webpage. I have ISA 2006 with the supportability update. It does not work at all with Firefox or non IE browsers.
How do I get rid of this? I have searched the internet for days without finding any useful information.