Octopus Cloud Communication Issue

The majority of our internal hosts are communicating with Octopus Cloud without issue. However, we have two hosts that reside in a subnet different than the rest, which can make the initial connection for polling tentacle install, but then is rejected.

Our infrastructure team would like to confirm that the public IP these hosts reside behind has been allowed on the Octopus side. Who would be able to help us with that? Thanks.

Hi @CHager!

Thanks for reaching out, and sorry to hear you’re having issues here.

Octopus cloud does not have any filtering on IP addresses for polling connections, so there are no explicit whitelists that need to be adjusted for polling communication to the cloud instances.

Typically we see this occurring in scenarios where outbound traffic is blocked on tcp/10943.

During the registration, a polling tentacle will initially reach out over tcp/443 (HTTPS) to register itself via the API, and after that, it will use 10943 to connect and collect work.

I hope this helps, and please let me know if you have any further questions.

Thanks for replying, Justin. That’s good to know on the IP filtering.

The networking folks say they can see the initial outbound connection being made during the Server connection while installing the tentacle. However, it’s failing with the following:

Error: Unable to connect to the Octopus Deploy server. See the inner exception for details.
An error occurred while sending the request.
The underlying connection was closed: An unexpected error occurred on a send.
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
An existing connection was forcibly closed by the remote host
System.Exception: Unable to connect to the Octopus Deploy server. See the inner exception for details. ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)
   at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)
   --- End of inner exception stack trace ---
   at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
   at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
   --- End of inner exception stack trace ---
   at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
   at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)
   --- End of inner exception stack trace ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Octopus.Client.OctopusAsyncClient.<DispatchRequest>d__57`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Octopus.Client.OctopusAsyncClient.<Get>d__36`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Octopus.Client.OctopusAsyncRepository.<LoadRootDocumentInner>d__203.MoveNext()
   --- End of inner exception stack trace ---
   at Octopus.Client.OctopusAsyncRepository.<LoadRootDocumentInner>d__203.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Octopus.Client.OctopusAsyncClient.<Create>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Octopus.Client.OctopusAsyncClient.<Create>d__15.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Octopus.Manager.Tentacle.TentacleConfiguration.SetupWizard.TentacleSetupWizardModel.<VerifyCredentials>d__197.MoveNext()

Hi CHager,

Thank you for getting back to us. Justin isn’t online just yet.

We usually see that error when something between the Tentacle and the Octopus Server is causing the polling connection to drop. Some of the usual suspects are host firewalls, network firewall appliances, anti-virus software, intrusion protection software, proxies, router filtering and other network appliances that can intercept traffic.

You mentioned that the Tentacles are on a different subnet which might suggest something at the boundary is not allowing both TCP ports (443 and 10943) through. Could you please ask your network team to look into this and compare the network configuration to the working Tentacles and the subnet they are on?

I hope this is helpful. Please let me know if you have any questions.

Best Regards,

Charles

Thanks for the reply, Charles. Sorry for the delay, I’ve been out of office. The Infrastructure folks determined these two hosts are in a DMZ subnet, and discovered an additional NAT rule that was interrupting this traffic. They updated the rule and now the hosts register successfully with Octopus Cloud. This is resolved.

Thanks for engaging, and for your troubleshooting suggestions!

1 Like