Good morning,
We have been doing development and testing in our labs just fine. Then of course take it out to a client… issues.
Env: Our octopus server lives in the cloud and the polling tentacles live on servers behind firewalls in client managed datacenters
Symptom: I couldn’t install the client via script. Issue registering during the register machine. I could go through the GUI verify the API key and then select roles and everything like I would expect (through HTTP 443 I guess), the instance would install and also fail to register. Finally, I managed to get access to the Layer 7 firewall …
Cause: I found that the ssl traffic of port 10943 was considered as an unknown application and blocked.
Commentary: While the simple response is “add a rule”. This is one option but this solution is aiming to go into may clients of size and would likely have layer 7 firewalls. Explaining and asking and getting through the change process with security would be very low on my list of things I want to deal with.
What I’d like do: is simply add another IP address to octopus server, get another ssl cert and bind 10943 polling tentacle port to new IP Address and change it to 443 port and poke one hole through the cloud VM firewall on the new IP. Did I miss finding how to do this in the documentation? Please advise if possible and how to do it? if not how else can I solve this? deploy a new node / instance on the same server, to the new ip with no web portal? do I use the same db or new DB? lots of ideas but just not sure the best path.
Thanks in advance.
Matt.
Hi Matt,
Thanks for reaching out. I’m sorry to hear you’re having problems with connecting Octopus to tentacles in an environment where opening TCP Port 10943 through the firewall is not an option.
Your current plan to use TCP port 443 or 80 instead of 10943 should work for you because polling tentacles don’t typically need any special firewall changes. Since your network only allow port 80 and 443 to the Octopus server, you can change the server bindings to either HTTP or HTTPS and use the remaining port for polling Tentacle connections.
One other option which comes to mind is to use your Polling Tentacles over WebSockets which will achieve a similar result but it will allow you to have your polling traffic and web traffic communicate on a shared HTTPS port.
I am interested to hear if websockets might suit your needs in this case.
Kind regards,
Lawrence.
With the older firewalls this traffic pattern works just fine, but with a layer 7 firewall the device actually inspects the application traffic and SSL on port 10943 is simply not your average or a known traffic pattern. To your average octopus user yes, but as far as palo alto is concerned it’s a potential threat. (I wonder Octopus can reach out to them and get yourself registered as a known application in the Palo Alto or other layer 7 firewall devices application list)
Websockets sounds like they could do the trick. Will try and organize this. Thanks for the response.
Hey Matt,
Thanks for keeping in touch, I would be interested to know if websockets works for your situation.
Kind regards,
Lawrence.