Tentacle pooling a server that sits behind Reverse Proxy

Although all the web site is working perfectly allright using a reverse proxy https://products.devscope.net/Deploy , the pooling tentacle wants to connect using a 10943 port.
My Firewall/ReverseProxy (TMG) doesn’t like that untrusted SSL + client cert auth mechanism. I’ve seen more people struggling with LoadBalancers here in the foruns. The problem is that 10943 is forcing a custom port, an untrusted server SSL, and forcing a client cert (also untrusted). All of these are really bad choices for any Load Balancer or Reverse Proxy.

My suggestion:
Don’t use any sort of custom ports. Many networks depend on 80 or 443, nothing else.
Don’t use the transport to Authenticate. The protocol should simple use the transport to tunnel, not to authenticate.
If you need machines (tentacles) to authenticate, just generate a token for them and then use that to authenticate to the API (over the same HTTP/HTTPS endpoint)

After authorizing a pooling tentacle, I would expect it to simply work using the exposed API, for example a route like https://products.devscope.net/Deploy/api/

BTW: any idea how to expose the 10943 over a reverse-proxy (hacking style)?
thank you.

Hi Jose,

Thanks for getting in touch! I understand you have some concerns about how we’ve implemented some aspects of Octopus, but I’ll get started with helping you resolve your Tentacle connection problems.

Resolving Tentacle connection problems

When it comes to exposing a non-standard port over a reverse-proxy, that depends on your proxy server and your specific requirements. Normally we would recommend simply port-forwarding requests for TCP Port 10943 from the public interface to your Octopus Server, and in the case of ISA Server, that’s what I would do.

If you really need to traverse through a reverse-proxy, that should be fine too, but I can’t help with the proxy configuration, but I can help with Octopus.

Which version of Octopus Deploy are you using? We just shipped Octopus 3.4 which adds support for Tentacles to connect to the Octopus Server via HTTP Proxy: http://docs.octopusdeploy.com/display/OD/Proxy+Support

We have written a comprehensive troubleshooting guide for Polling Tentacles and I’d appreciate it if you could go through that and get back in touch if you need further help: http://docs.octopusdeploy.com/display/OD/Troubleshoot+Polling+Tentacles

Tentacle communication concerns

I appreciate you taking the time to share your concerns with us. We haven’t made any of these decisions lightly, and I’ll go to some effort to provide some background.

This article should give you some more insight into the design of the Tentacle - Octopus Server communication: http://docs.octopusdeploy.com/display/OD/Octopus+-+Tentacle+communication

Self-signed certificates

This blog post should explain why we chose self-signed certificates in the first place: https://octopus.com/blog/why-self-signed-certificates

Out of the box we use self-signed certificates as a convenience for customers who don’t have their own PKI, or don’t have the experience to work with PKI, or simply don’t care to manage it themselves. As long as the trust relationship between the Octopus Server and Tentacles are maintained, self-signed or not, that’s OK - all of the benefits of TLS still apply.

If you want to, you can use custom certificates on both sides of the relationship: http://docs.octopusdeploy.com/display/OD/How+to+use+custom+certificates+with+Octopus+Server+and+Tentacle

Client certificate authentication

In the case of Octopus Server - Tentacle authentication - we are just using TLS Client Authentication provided out of the box by .NET which leverages Schannel in Windows servers: https://technet.microsoft.com/en-us/library/cc784450(v=ws.10).aspx

Whilst I can see plenty of usability problems with Client Certificate Authentication schemes, it makes a lot of sense for Client-Server relationships, especially because Octopus owns both sides of the relationship, and can wrangle the certificates on your behalf if you want it to.

Custom TCP Port

We didn’t originally have Polling Tentacles, only Listening Tentacles which listen on TCP Port 10933 by default. The reason for the custom TCP Port is because Tentacle is usually running on a Web Server which is already trying to listen on Port 80 and 443 to host web sites - and it wouldn’t be nice if Tentacle caused web sites to fail due to a binding conflict. This way customers can have control over which TCP Ports they open and bind to and for which reasons.

When Polling Tentacles were introduced, we followed suit and made them listen on a custom TCP Port 10943 by default. Again, people often host their Octopus Server on the same machine as other services, and we wanted to give control to our customers, hence why you can configure the Octopus Web bindings, and the Tentacle port.

Granted it would be convenient if Polling Tentacles could just poll against the same HTTP interface as the standard web traffic for the Web Portal, but this isn’t easily achieved since Tentacle uses TLS but doesn’t implement HTTP - it uses a custom transport called Halibut: https://github.com/OctopusDeploy/Halibut Perhaps in a future version of Octopus Deploy we’ll be able to simplify this further.

Hope that helps!

Hi Jose,

I was just going through our UserVoice site and came across this suggestion which lines up with yours. Feel free to add your vote!

Hope that helps!