Web-request from Octopus Server not sent via configured proxy

Octopus Server
, ,
1

Hi
After upgrading to 2019.10.1 (currently on 2019.10.9 with the same issue) we get errors in the web-ui when:

  • Adding new Azure web apps (fails to load the dropdown for “Azure Web App”)
  • Selecting “Azure Web App Slot” on existing WebApp (error: An error occurred while sending the request. Unable to connect to the remote server No connection could be made because the target machine actively refused it 40.126.1.129:443)
  • “Save and Test” on new and existing Azure-account
    However, health-checks and deployments to existing “Azure Web App”-targets work as intended.

Our environment requires all outgoing web-requests to be sent via a proxy, so the server is configured to “Use a custom proxy server” with host and port set.

Some digging with procmon seems to suggest that the Octopus Server-process tries to contact the Azure resource directly while Calamari connects to the proxy-server.

oct_proxy_procmon-result
oct_proxy_procmon-result.png1011×643 96.1 KB

3

Hi @hallvard.vasstveit,

Thanks for getting in touch!

We discovered that this was a bug recently and have raised an issue for it. At the time we’d only seen it affecting Powershell scripts so the suggested workaround is targetted at that.

This issue was related to how the bypass list was passed along to the Octopus Server, would that correlate with your own configuration?

I’ll run this past the engineers again to advise that it is manifesting in this way regarding Azure web apps and that there isn’t any viable workaround.

Best regards,
Paul

4

Hi @paul.calvert,

We have no buypass list set, so all traffic should be sent to the proxy. These are the settings in OctopusServer.config that are set:
set key=“Octopus.Proxy.ProxyHost”>proxy…</set
set key=“Octopus.Proxy.ProxyPort”>8080</set
set key=“Octopus.Proxy.UseDefaultProxy”>false</set

There is also no IE or Machine-level proxy set on the server

Best regards,
Hallvard

5

Hi Hallvard,

Thanks for clarifying that.

I’m struggling to replicate this.
I’m using my proxy test environment with the following configured in Octopus Server:


  <set key="Octopus.Proxy.ProxyHost">paul-virtual-machine</set>
  <set key="Octopus.Proxy.ProxyPassword" />
  <set key="Octopus.Proxy.ProxyPort">3128</set>
  <set key="Octopus.Proxy.ProxyUsername" />
  <set key="Octopus.Proxy.UseDefaultProxy">false</set>

And I can create and modify Azure web app deployment targets without a problem.
ProcMon is showing it hitting the proxy as expected too:

image
image.png1411×192 152 KB

When I tested using a second instance on that VM that doesn’t have the proxy configured, I see this error when it tries to retrieve the web app list, do you get the same?

image
image.png1021×762 18.1 KB

Regards,
Paul

6

Hi, Paul

I get the same error as you on the instance without proxy-configuration:

add_web_app_error
add_web_app_error.png1009×796 42.4 KB

And this is the traffic in ProcMon:
add_web_app_error_procmon

There has been a couple of new releases since the one we are running (v2019.10.9), but i cannot see any proxy-issues in the changelog: https://octopus.com/downloads/compare?from=2019.10.9&to=2019.10.11

Regards,
Hallvard

7

Hi Hallvard,

“Good” news, I managed to figure out why mine was working. I had left the proxy configured in IE. With the proxy disabled in IE, it now fails to load the app list.
It seems like it is ignoring the custom proxy details entered into Octopus and defaulting to using whatever is set to IE.

You mention that you saw this occur after upgrading to 2019.10.1, I’d like to perform this same test in the version you were using prior to the upgrade, can you confirm what version that was for me?

Regards,
Paul

8

Hi Paul,
We used 2019.8.5 prior to 2019.10.1

Regards,
Hallvard

9

Hi Hallvard,

Thanks for confirming that, I’ve just tested with that version and it works fine, updated to the latest and it starts throwing the error, so this does look like a bug. I will raise with our engineers for triage and add a link to the GitHub issue once raised. With the timezone difference it may be Monday before this is complete.

In the meantime, would you be able to test a workaround for me?
Could you try adding your proxy details to IE Internet Options and seeing if that works for you? I’m fairly certain it will fail, as the user that the Octopus service is running as likely won’t have access to the IE proxy settings, but it would be good to confirm.

Best regards,
Paul

10

Hi Paul,

Thank you for the update

I tried adding the IE-proxy settings to my user both on client loading the webpage and server, but it does not work as you suspected. I could probably add it to the service account used to run the service, but since we do not add new targets often our current workaround is just adding them using the API.

Best regards,
Hallvard

1 Like