Load Balance http conversion to https

Hey Guys, So I' ve been told by Fortinet Support that http-location-conversion does not actually change the host header from http to https. I am about to blow my top. I' ve been working on this fix for a loooooong time and support is now trying to tell me that the following doesn' t actually mean that the FGT is suppose to reply with https: " Select to replace http with https in the reply’s Location HTTP header field. For example, in the reply, Location: http://example.com/ would be converted to Location: https://example.com/ . This option appears only if type is server-load-balance and server-type is https." I just don' t understand how they can do this. I' ll post the end of the thread here because it just seems completely backwards. Especially the part about them telling me this would be a feature request. I' m still completely confused as to what they are saying http-location-conversion is suppose to do. Can anyone clear this up for me? Also, if anyone can answer my question that is in bold (that has still not been answered by Fortinet Support) I would be forever in debt. Support thread starts here....... Thanks Nelson. I tried the header check and got very inconsistant results. https:// requests failed on almost every request that I tried. Including well known working sites. I understand that you are saying that http-location-conversion doesn' t do a http to https redirect. However, replying with https as the header will replace https in the browser and then the browser will request on port 443. One question i desperately need answered: How do I use any server/hardware/service behind the FGT to redirect to HTTPS when the FGT is providing the certificate and ONLY accepting traffic on port 443? As far as I can tell there is no way for traffic on port 80 to get past the FGT in order to allow me to use any other tool to redirect from port 80 (http) to port 443 (https). Please, please, please, please answer that question because with that information I can troubleshoot and purchase something that will effectively do what we need. I' m still very unsure that this " feature" doesn' t already exist. If the FGT is an acting load balancer with SSL offloading, then the real servers will never, ever, ever, handle anything on port 443 which is in fact, https. Using the real servers on port 443 with their own certificate would completely disregard the need for SSL Offloading in general. I would love for these above questions to be answered or at least addressed, but I understand that this is being regarded a feature request. Fact is, the other users on the forum have stated that they have things working exactly as they should with the configuration we have been working on. This is why I don' t believe that this feature doesn' t already exist. I' d like to know what http-location-conversion is actually used for if it is not used to reply to the browser to use https instead of http. Thanks again for sticking with me through all of this. However, I would really like it noted that I don' t think things are working as the manual states they should. The " reply" is simply not working. Nick. 2/17/2012 12:44:00 PM Nelson Paredes Hi Nick, I' m sorry for the late reply. I' ve been researching and trying to clarify what the setting is supposed to do. I' ve looked at our documentation and wanted to share the option to use WCCP to redirect traffic to a proxy (IIS server with proxy enable). The only thing is that you either need to fortigates so that one works as the WCCP (client) and another one as the WCCP (server) while keeping your existing configuration for load balancing using the virtual IP' s. The second KB article uses a squid proxy as an example. I' ve gone through our documentation in detail as there are no clear statements or procedures that could confirm that the fortigate can do redirects from http to https using the " set ssl-http-location-conversion" . We have another device called fortiweb that protects web servers and it does have the functionality to do http redirects on the other hand. I' d like to suggest looking at the following KB articles and tell me if this is something that would meet your requirements. Sample configuration of FortiGate WCCP server and client (traffic redirector and transparent proxy) http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD32926&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=29443176&stateId=0%200%2029441390 Configuring WCCP interception of HTTP traffic to a squid proxy using GRE tunneling (in your case you have IIS and it would require you to enable the proxy option) http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD30096&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=29443202&stateId=0%200%2029441419 These two KB articles are some thouhgts as an alternative solution. Please see below about the difference between location conversion and redirection: This is what the CLI states: ssl-http-location-conversion {enable | disable} Select to replace http with https in the reply’s Location HTTP header field. For example, in the reply, Location: http://example.com/ would be converted to Location: https://example.com/ . This option appears only if type is server-load-balance and server-type is https. My understanding is that the http conversion parameter should change the location of the request to https and then the web server redirect from http to https. I' ve consulted with senior engineering about this feature and it' s not supposed to redirect traffic but to replace the location. The documentation does not specify that the fortigate will redirect http to https traffic. This is what I would expect to happen when you do the request if a web server does the redirection: 1. The client types http://myportal.mcnallysmith.edu in the address bar 2. The browser assumes HTTP protocol and sends a GET call to http://myportal.mcnallysmith.edu 3.http://myportal.mcnallysmith.edu responds with a moved status code and gives the new location: ---> task performed by a web server in general HTTP/1.1 301 Moved Permanently Location: https://myportal.mcnallysmith.edu 4. The browser reads this location and knows that it must now start a SSL connection. 5. The browser and the server exchange multiple messages until the secure connection is established such as client hello, Server Hello, Change Cipher Spec, Encrypted Handshake Message TLSv1, etc. If you install a SSL certificate you must make sure that your client is redirected from HTTP to HTTPS. That is accomplished from the server configurations. Normally from web servers such as: IIS, Apache, SunOne, iPlanet, etc. The functionality of the redirection can be noticed when sniffing the traffic to a secure site as you will see in a packet capture when looking at the http.request call. The location changes to https and it tells you the name of the application that did the redirect. Example redirection: GET / HTTP/1.1 Host: www.example.com Connection: keep-alive User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Ubuntu/10.10 Chromium/13.0.782.112 Chrome/13.0.782.112 Safari/535.1 HTTP/1.1 301 Moved Permanently ----------> web server transparently responds with this message while doing the redirection Server: Sun-ONE-Web-Server/6.1 ----------> web server that does the redirection from http to https Date: Fri, 17 Feb 2012 18:51:21 GMT Content-length: 0 Content-type: text/html Location: https://example.com/ ----> you can see in this example that the location is replaced with the location as https. Another example is online shopping websites, you can browse via http but as soon as you add an item to the shopping cart and do a checkout, you get redirected to a https URL and can see the server as Microsoft-IIS/6.0 as an example. A financial institution as another example will redirect you from http to https as they install the ssl certificate on their web host. Let me know if this clarifies what the setting' s function is expected to do. In regards to the SSL Offloading options, this is the expected functionality of the fortigate: (The KB refers to client to fortigate or ssl-mode = half and client -> fortigate -> server or ssl-mode = full) http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=13652&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=29447316&stateId=0%200%2029445590 Regards, Nelson Fortinet TAC Americas M-F 12-9pm EST 1-866-648-4638 https://support.fortinet.com 2/21/2012 7:14:00 AM Nick Kaihoi Thanks Nelson, Also, thanks for the detail however I still don' t have my main question answered. How I would use IIS to redirect when the VIP only allows traffic on port 443? If the VIP will not allow http traffic to get to IIS (or apache) to redirect to https, I cannot use any of the solutions above. This is the problem, if I use SSL offloading, the external port on the VIP needs to be 443. This means port 80 traffic will never get to the IIS server to redirect because the VIP is not listening for it. If there is no solution to this, please tell me. I will be posting this information to the forums for additional assistance because the users were able to get this working in the manor that I need. Nick.

Hi Nick, I' m a bit puzzled to find such a question to be solved by a Fortigate. This is (in my humble opinion) something to be handled by a webserver behind a Fortigate. So if a client connects to http in stead of https on the webserver you give a php relocate or via some other (webserver) means. It' s something simple for a webserver so why don' t you fix it there?

Hi Eric, Thanks for the reply. In order to use SSL offloading on the FGT, one must configure the cert on the FGT and then tell it to communicate with the real servers via port 80. It would look like this: Client<---443--->FGT<---80--->Real Server However the looming question is related to defining the external port on the LoadBalanced VIP, in this case it' s 443 (as described by the manual to use SSL offloading and placing the cert on the FGT). You have to choose a single port when using VIP-Type HTTPS or HTTP). Referring to your question: It' s something simple for a webserver so why don' t you fix it there? I' m unable to do this is the external port is 443. If I change the port to 80 and try to configure relocation on the webserver, the relocation " happens" but then the client cannot get past the firewall on 443 because it' s external port is set to 80. This is what I assume http-location-conversion is setup to do. It' s suppose to reply to the client from the FGT to use https instead of http, I would also assume this would allow the FGT to accept traffic on port 80 just to make the reply functional...however that' s not the case. I hope you understand why I cannot figure out a way to do this on the real web servers themselves. Any ideas are greatly appreciated as I don' t really care how it' s solved, I would just like it solved. I would like to make an update that Fortinet' s support management has been more than helpful in trying to resolve this issue!! Nick.

so if you forward the port 80 traffic on the outside via port forwarding to a redirect server and there redirect to 443 and that would hit the loadbalancing rule. The culprit is here that you want to use offloading. There is another way and that is the www.mydomain.com is only reachable on http and that redirects to https://www.mydomain.com/web then you can do it on all servers Just curious Which type of Fortigate are you using and how much traffic do you expect?

310b and I' m not sure what to tell you as far as traffic. There are about 2000 users who would need access to this portal. We are a college and this system is the Student Information System which is how all faculty, staff, and students do everything from applying to the school, class schedules, faculty/student communication, and job searching. To setup an outside accessible load balance (from what I know...) it needs to be setup on the outside interface. In order to use your first solution we would need to have a different URL/IP because the FGT will not allow me to create a Virtual IP with the same outside address as the Load Balanced Virtual IP with one accepting connections on 80 and the other on 443 respectively. I hope I understand what you were suggesting...If not please feel free to correct me. I' m curious how to use your second recommendation using the FGT to load balance. Thanks again for your help!! Nick.

Why not load balance port 80 AND port 443 to the same private servers?

Working with Fortinet support we are going to try something similar to what you' ve suggested. IIS will force the client to use port SSL over port 443. SSL offloading mode will have to be set to full but this shouldn' t be a problem with a self signed cert on the real servers because they will ignore cert verification. I won' t be able to test this until tomorrow but I will keep you all up-to-date. Problem is, I tried this months ago with no luck...hopefully I missed something and it will work this time. Nick.