Translating an F5 rule

[Jeffrey 'jf' Lim]

On Wed, Mar 20, 2013 at 3:05 PM, Igor Sysoev <igor at sysoev.ru> wrote:
> On Mar 19, 2013, at 19:42 , WBrown at e1b.org wrote:
>
>> Peter Booth wrote on 03/19/2013 10:43:12 AM:
>>
>>> The code does the following:
>>>
>>> 1. remove an HTTP header named "SWSSLHDR"
>>> 2. replaces it with SWSSLHDR: port, where the port is the local port of
>>> the "current context's TCP connection", presumably the port that your F5
>>> virtual server is listening on.
>>
>> I had somewhat figured that out.  It isn't clear from the notes I got from
>> vender as to what the current context is.  I'm guessing the client side,
>> but I can test that.
>>
>>> This is presumably to separate SSL and non SSL traffic , or to allow for
>>> load balancing across websites that are hosted on ports 8080, 8000 or
>>> other nonstandard ports.
>>>
>>> One thought- are you configuring the nginx server to terminate SSL and
>>> then proxy to a single upstream endpoint? Is this the same topology as
>>> the F5 one? Is the entire site SSL or just the login portions?
>>
>> Presently, we are using an Centos box with Piranha for load balancing, but
>> we wish to implement SSL.  There are about 50 sites hosted with three
>> upstream servers.  I don't want to tie up 150 IP addresses for SSL on
>> them, so I want to terminate the SSL connection at the nginx server and
>> use HTTP on port 80 to connect from nginx to IIS.
>>
>> The F5 information is just what the IIS application vendor says they use
>> in their configuration.  We may be buying an F5 in the future, but I need
>> SSL in the short term.
>>
>> Would I add to the location section something like this:
>>
>>        more_set_input_headers -r SWSSLHDR $server_port
>
> proxy_set_header  SWSSLHDR  $server_port;
>

nice catch! But once again, because HTTP_REQUEST is client-side, so
says this F5-certified engineer with reference to the docs, it should
be $proxy_port instead of $server_port.

-jf