DotNetNuke is more and more being used and implemented in enterprise environments.  Having recently celebrated its 6th anniversary, it has become not only a full featured application framework/content management system, but a VERY stable environment for deploying high quality sites that demand high availability and quick response times.  Different companies, of course, go about providing the "high availability and quick response times" in different ways: load balancers, web farms, etc.

As of version 4.5.x (I believe) DotNetNuke introduced support for SSL as a core feature of the framework.  This functionality allows you to enable SSL on the site, which instantly cause all host and portal admin pages to be redirected to an HTTPS URL, and selectively individual pages on the site to be required to be viewed over HTTPS as well.  By enabling SSL on DotNetNuke, and marking a given page as "Secured", DotNetNuke will no longer allow that page to be viewed over the unsecured HTTP URL.  This presents a HUGE challenge when you've got what I refer to as an "intelligent" firewall/load balancer in between the web server hosting DotNetNuke and the end user's browser. 

Let me explain...  Every time a user browses to a new page on your DotNetNuke website, at least one (if not several) requests are made from the user's web browser to the web server.  If the page is being viewed over an SSL link the user's request is encrypted by the user's web browser, and then decrypted by the web server.  Next, the web site's response is encrypted by the web server, and then decrypted by the user's web browser when received.  The conversation looks something like this:

(User's Web Browser) <--- Encrypted ---> (Web Server)

While the processing of a few of these requests would likely take less than a second, if you have a website with 10,000, 100,000 or even more hits a day, then the encryption/decryption process on the web server could amount to minutes or more of processing time.  Granted a few minutes a day doesn't sound like a lot, but remember users require quick responses times so whatever that can be done to speed that up will make users happier.  Somewhere along the way the firewall/load balancer companies realized that if they could offload the SSL encryption/decryption process from the web server, it will make the web servers more responsive. So when you put one of these "intelligent" devices in between the end user's browser and the web server, the conversation goes more like this:

(User's Web Browser) <--- Encrypted ---> (Firewall/Load Balancer) <--- Unencrypted ---> (Web Server)

The unencrypted traffic is not a problem, because it is assumed that the firewall/load balancer is on the same local network as the web server, so the chance of the data being captured and compromised is unlikely.  This presents a HUGE problem for companies implementing DotNetNuke and enabling SSL and secured pages though.  At the point you turn on SSL and secure a page, DotNetNuke will NOT let you view that page without HTTPS in the requested URL.  If you try to view a given page over standard HTTP, it will perform a 302 redirect to the HTTPS URL, to which the end user's browser will respond by going to the HTTPS URL, which the firewall/load balancer strips and turns in to a HTTP request to the web server, to which the DotNetNuke site does a 302 redirect to the HTTPS URL...You get the idea...

As of this writing the only solution I know of (short of modifying core code in the DotNetNuke framework), is to NOT enable SSL and secured pages in DotNetNuke, and hard-code links to pages you'd like to have viewed over SSL with an HTTPS URL.  This will allow the end-user to view the site using SSL, but allow the firewall/load balancer to perform requests to the web server over HTTP.  I personally would like to see the DotNetNuke team make some modifications to the core framework that allows for the hardware environment I've described.  An example would be them allowing you to mark a page as "secure" without enabling SSL for the whole site.  This would tell the site that when you go to a given page to provide an HTTPS URL, but not require that page be viewed over SSL.  I've submitted the described situation to their bug tracker, and have yet to receive a response.  This will require some discussions on their part, and some thinking about the overall architecture of how to implement a proper solution to this situation.

So, if you are running into a similar situation on your DotNetNuke site (as of version 4.9.1, and 5.0.0), the only "easy" solution is the one I've described above.  Hard code your links to secured pages to HTTPS, but don't enable SSL or secured pages on your site.