BaGet: Cannot push nuget packages to BaGet behind an IIS Reverse Proxy

Describe the bug

I’m using BaGet inside a windows docker image. IIS 10 is used as a reverse proxy. This is the web.config file used to proxy queries with the pattern domain.de/nuget/ to the BaGet server which is running in a Windows Docher container on another machine with the IP 192.168.178.2.

		 <rule name="nuget" stopProcessing="true">
                    <match url="nuget/(.*)" />
                    <action type="Rewrite" url="http://192.168.178.2:5555/{R:1}" />
                    <serverVariables>
                        <set name="HTTP_FORWARDED" value="for={REMOTE_ADDR};by={LOCAL_ADDR};host=&quot;{HTTP_HOST}&quot;;proto=&quot;https&quot;" />
			<set name="HTTP_X_FORWARDED_HOST" value="{HTTP_HOST}" />
			<set name="HTTP_X_FORWARDED_SCHEMA" value="https" />
			<set name="HTTP_X_FORWARDED_PROTO" value="https" />
                    </serverVariables>
                </rule>

This is my baget.env :

ApiKey=NUGET-SERVER-API-KEY
PathBase=/nuget
Storage__Type=FileSystem
Storage__Path=c:\packages
Database__Type=Sqlite
Database__ConnectionString=Data Source=C:\packages\baget.db
Search__Type=Database

When Im running however the nuget push command it uses the internal IP address (the url of docker container) and not the one of the proxy.

$ dotnet nuget push  -s https://proxydomain.de/nuget/v3/index.json -k NUGET-SERVER-API-KEY package.nupkg
info : Pushing package.nupkg to 'https://192.168.178.2:5555/api/v2/package'...
info :   PUT https://192.168.178.2:5555/api/v2/package/
info : An error was encountered when fetching 'PUT https://192.168.178.2:5555/api/v2/package/'. The request will now be retried.
info : A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
info :   PUT https://192.168.178.2:5555/api/v2/package/
info : An error was encountered when fetching 'PUT https://192.168.178.2:5555/api/v2/package/'. The request will now be retried.
info : A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
info :   PUT https://192.168.178.2:5555/api/v2/package/
error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

The angular UI isnt running at all. Thats seems to be however the typical problem with the base element not set correctly.

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 2
Comments: 32 (2 by maintainers)

Most upvoted comments

@loic-sharma Yes you’re right, these are two separate issues. The ForwardedHeaders.XForwardedHost should fix the first issue. The second is (in my opinion) not only just a nice to have. Usually when using a reverse proxy, you want to redirect multiple applications to different servers. For example:

nginx/app1 => appserver/app1
nginx/jenkins => buildserver/jenkins
nginx/nexus => nexusserver/nexus

Without the possibility to host an application under a subpath, it is (as far as I know) not possible to use it in a normal reverse proxy scenario.

Roemer on Jun 11, 2019

This is an IIS configuration issue not a BaGet issue.

This is the BaGet issue. When you run a push command from CLI, nuget.exe will request for a config json file that contains all necessaries urls. It then cache that config file at \AppData\Local\NuGet\v3-cache\<some random string>$_nuget.devmoba.com_v3_index.json and use the settings in that file to continue the process (of pushing packages). Changing some IIS config will definitely not help you to change this file 's content.

So, my work around is manually change all the URLs in that file to http://my.company.name instead of http://locahost:xxxx Hopefully the next release will let us change this by a setting line.

trgiangvp3 on Aug 3, 2020

This is an IIS configuration issue not a BaGet issue. The first setting you need to check on your re-write server is the server level setting: system.webServer/proxy: preserveHostHeader. If this is set “True” then the request “Host” header will be passed through to the destination server. And you don’t need to worry about X-Forwarded or any of that confusing misdirection. If it is set to “False” then ARR will rewrite the Host header to reflect the host hame of the server is is redirecting the request to. i.e. 192.168.etc. Usually not what you want. One way to fix this is clearly at this level but as the system.webServer/proxy preserverHostHeader setting applies server wide that might have unintended side effects if the server is hosting other loads making use of the proxy. In which case, a simple rewrite of the rewrite rules has you covered:

So, first add “HTTP_HOST” to the list of Allowed Server Variables, then ammend your rewrite rule to have a condition and server variable rule like this :-

            <rules>
                <rule name="test" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTP_HOST}" pattern="(.*)" />
                    </conditions>
                    <serverVariables>
                        <set name="HTTP_HOST" value="{C:1}" />
                    </serverVariables>
                    <action type="Rewrite" url="http://example.com/{R:1}" />
                </rule>

As conditions are always processed before the rules are triggered, they captures the “Host” header as {C:1}, and then serverVariables are applied hopefully after ARR and Rewrite have done their other modifications, where we set it back to the original - passed in - value.

Again. No need to mess around with non standard X-Forwarded etc. headers.

chrisbecke on Nov 22, 2019