How to Configure IIS as a Reverse Proxy for Sonatype Products

The Nexus documentation provides steps for configuring Nexus Repository Manager to run behind a reverse proxy. The information below will help you configure an IIS server to act as a reverse proxy server.

  1. On your reverse proxy server, install IIS and Application Request Routing following the product documentation
  2. Using the IIS Manager console, select the Default Web Site and open URL Rewrite.
  3. Use URL Rewrite to create your inbound rule. From the Actions pane, select the Add Rule… template and create a new Reverse Proxy rule. Click OK to enable proxy functionality if you are prompted. Choose a name for your Inbound Rule and click OK.
  4. Create server variables for the HTTP headers. In the Actions pane, click View Server Variables. Add the following variables:
    HTTP_X_FORWARDED_HOST
    HTTP_X_FORWARDED_PROTO
    then click Back to Rules.
  5. Set values for the server variables in your inbound rule. Highlight the Inbound rule and click Edit. Under Server Variables click Add. Select the server variable names from the drop down and assign the following values:
    HTTP_X_FORWARDED_HOST should contain the domain name and (optionally) port of the original host requested by the client 
    HTTP_X_FORWARDED_PROTO should be https if your IIS server is configured to use SSL, otherwise http
    
  6. Restart IIS. In the Connections pane select the server name, then Restart the server from the Actions pane.

Once your configuration is complete, the web.config file in inetpub\wwwroot will contain entries similar to the following:

<rules>
    <rule name="ReverseProxyInboundRule1" stopProcessing="true">
        <match url="(.*)" />
        <action type="Rewrite" url="http://localhost:8081/{R:1}" />
        <serverVariables>
            <set name="HTTP_X_FORWARDED_HOST" value=“nexus.mydomain.org” />
            <set name="HTTP_X_FORWARDED_PROTO" value="http" />
        </serverVariables>
    </rule>
</rules>

With a reverse proxy in front of Nexus you may also wish to create a Base URL capability which the repository manager will use to construct correct URLs to the user interface within email notifications.

HTTP POST Requests Fail With 404 Status Code

Some interactions with Sonatype products use HTTP POST requests:

  • uploads using the Nexus Repository Manager 2.x user interface ( repository Upload tab and Staging Upload )
  • Nexus IQ Server Evaluate Binary action

These operations may require a POST request that exceeds the default content limits set by IIS ( approx. 28.6 MB). When this happens, the requests do not pass through to the Sonatype servers and are instead returned from IIS as a error with 404 status code, sub-status code 13, and a message Content Length Too Large.

Consult the official IIS documentation for options to allow for larger POST requests.

External References About Configuring IIS

Nexus Repository OSS reverse proxy 

IIS Forums

Troubleshooting Inbound Request Headers in Nexus Repository Manager

You can trace the HTTP request headers being sent to Nexus Repository Manager from a reverse proxy. This will help prove that your reverse proxy is sending Nexus the correct header values.

Find this file in a text editor:

Find this line that defines the request.log pattern - it should look similar to this:

  <pattern>%clientHost %l %user [%date] "%requestURL" %statusCode %bytesSent %elapsedTime "%header{User-Agent}"</pattern>

Change that pattern value so that additional inbound request headers are printed:

  <pattern>%clientHost %l %user [%date] "%requestURL" %statusCode %bytesSent %elapsedTime "%header{User-Agent}" %header{host} %header{x-forwarded-host} %header{x-forwarded-proto}</pattern>

...and then save the file, and restart Nexus.

Access Nexus through your reverse proxy server while monitoring the Nexus Repository Manager request.log

If a header is being sent to Nexus, it's value should display in the logs.

If a header is not being sent to Nexus, a single dash ( - ) will display instead.

HTTP header names are case insensitive.

Example: Reverse Proxy Terminating HTTPS on port 443

If your reverse proxy is configured correctly, then each line should look similar to:

192.168.2.110 - - [13/Dez/2016:14:41:45 +0100] "POST /service/extdirect/poll/rapture_State_get HTTP/1.1" 200 77 16 nexus.example.com - https

or possibly

192.168.2.110 - - [13/Dez/2016:14:41:45 +0100] "POST /service/extdirect/poll/rapture_State_get HTTP/1.1" 200 77 16 nexus.example.com nexus.example.com https

If request log lines do not end in https ( and instead just - ), then the reverse proxy is not sending the expected X-forwarded-proto HTTP request header that Nexus needs if the reverse proxy is terminating a HTTPS connection.

Troubleshooting IIS Reverse Proxy Problems

For troubleshooting IIS reverse proxy, Microsoft recommends enabling Failed Request Tracing which creates an xml file for each request. The IIS forums are also a good resource.

 

 

Have more questions? Submit a request

0 Comments

Article is closed for comments.
Powered by Zendesk