Elastic Agent port number change

[Ryan_Downey]

ECE 2.4
Elastic v7.10.1
Elastic Agent v7.10.1

I hit and issue with the "Enroll and start the Elastic Agent" step for Windows. The first error message that I started receiving was after running this in Powershell:

.\elastic-agent.exe install -f --kibana-url=https://
xyz.gov:443 --enrollment-token=R2pxxx0JRTxxxx186S2kxNUcUc4dU
ZYxxxxd3M3enxxx==
The Elastic Agent is currently in BETA and should not be used in production

The error message displayed was:

2021-02-10T10:39:31.023-0500 DEBUG kibana/client.go:170 Request method: POST, path: /api/fleet/agents/enroll
Error: fail to enroll: fail to execute request to Kibana: Post "https://xyz.g
ov:443/api/fleet/agents/enroll?": dial tcp xx.xx.xx.xx:443: connectex: No connection could be made because the target machine actively refused it. Error: enroll command failed with exit code: 1

This was solved in Elastic Cloud Enterprise by changing the port from 443 to 9243 so the actual command to enroll ended up being; .\elastic-agent.exe install -f --kibana-url=https://
xyz.gov:9243 --enrollment-token=Xh1R2pxxx0JRTxxxx186S2kxNUcUc4dU
ZYxxxxd3M3enxxx==

Not a crazy issue to resolve but it did require a bit of troubleshooting and is something that could be updated in the docs or changed in Kibana where it populates. From there the beat will enroll and show up in the appropriate Fleet tabs in Kibana. However, once it runs for a little bit the Agent drops out and the error message in the logs is

2021-02-10T13:49:16.023-0500 DEBUG kibana/client.go:170 Request method: POST, path: /api/fleet/agents/f28434b2-3bb8-458e-a0f0-8f626ac75ce4/checkin
2021-02-10T13:49:17.038-0500 ERROR application/fleet_gateway.go:176 Could not communicate with Checking API will retry, error: fail to checkin to fleet: Post "https://xyz.gov:443/api/fleet/agents/xxxxx-xxxxx-xxxx-xxxx/checkin?": dial tcp xx.xx.xx.xx:443: connectex: No connection could be made because the target machine actively refused it.

From what I can tell I need to change a setting somewhere so that the API stops utilizing port 443 but I'm not sure where that needs to be done.

[Alex_Piggott]

Where did you get the snippet that had 443?

I think all our "cloud docs" use that because it's the recommended value when using ESS (the version we host)

The "dynamically generated" docs that are in Kibana should use whatever port is configured for your ECE (9243 by default). Any cloud ids ("all-in-one" param for beats config) that are generated by ECE should also reflect reality.

[Ryan_Downey]

I just utilized the link from the "Add Agent" section at the bottom. Its possible I'm looking at the wrong docs or have missed it. So basically I went to add an agent, copied the link and hit the error which took me a bit to realize what it was erroring out on.

Image is a snippet of what populates in our ECE environment during setup. Maybe I'm missing a configuration step?

So that was the initial enrollment step, now it disconnects after enrollment.

[Alex_Piggott]

Interesting, it certainly looks like it's specifically adding 443 from the config store. If you go to the deployments overview page in ECE, there should be a cloud id (long base64 key). If you base64 decode that, it should report whether the ECE port is configured as 443 (or its default 9243)

[Alex_Piggott]

Ah ha never mind, I just remembered this got opened as a bug in our internal tracking repo last week! So apologies, should be fixed in a future release

[Ryan_Downey]

Cool, cool, I also think I found the solution. I should have a report back in like 10 min or less. Just need to do some uninstalling and reinstalling to test my theory.

[Ryan_Downey]

Ok, so I don't want to speak to quickly but after a quick test the issue appears to be the url the Settings populated in our ECE deployment, v 7.10.1. The Settings in the upper right hand corner of the Fleet overview page defaults the docker container to 443 (at least in this instance). Due to the length of the container name I made the ASSUMPTION that this was correct so I never checked it. Once I hovered over it both ursl's ended in :443. A quick update to those URL's seems to have fixed the issue. Not sure if this in the doc and I just rushed past it, user error is always a possibility, or if its just part of the fine tuning process during Beta.