SAM 6.2 agent configuration issue?

So here is the scenario:

I am monitoring some VM's within the azure environment via passive agent (well, 1 at the moment). Meanwhile, I'm using azure's endpoint functionality to ensure that public port is port X while private port is 17790, which is I configure from the manually installed agent MSI. When I go into SAM -> manage agents -> connect to a previously installed agent, and then configure it for server-initiated communication and specify port X? The agent gets updated in Azure to port X, and then fails to connect.

Is this the intended behavior of the agent? This does tend to break the intended method of having a non-default public port for azure monitoring.

Find more posts tagged with

sam_agent

azure_endpoints

sam_6.2

troubleshooting

azure_monitoring

Accepted answers

patrick.hubbard

Matt, I just got an email with one line from you-know-who. "Turns out it’s a legitimate bug he found."

Nice job, and thanks for bringing the issue to Office Hours

All comments

patrick.hubbard

aLTeReGo‌ I think what Core is doing is looking at the TCP connection remote host port and then sending that to the agent as the target update port on restart, rather than asking the agent what its internal port is. I'm guessing that's a bug- most cloud would work as described above with a NATted public port for the agent. Thx!

aLTeReGo

Have you tried configuring the agent to use the same TCP port as the port forwarder when creating the package so they match?

Agent Port Download.png

designerfx

aLTeReGo as I discussed with patrick.hubbard‌ - it is obvious that such a scenario would work, and is what I am doing right now already. That is a workaround.

However, there is no point in even having NAT or any form of port forwarding if we can't have the agent handle it properly. Basically, what can be done to stop the agent overriding things once it goes through the forward port? If my public port is 17791 and the internal port is 17790, why would the server (connecting to the agent on 17791) then force the agent to update and be configured for 17791?

patrick.hubbard

Matt, I just got an email with one line from you-know-who. "Turns out it’s a legitimate bug he found."

Nice job, and thanks for bringing the issue to Office Hours