ADS Controller ignores settings and thus fails to connect to target

OS Name/Version: Ubuntu 20.04

Product Name/Version: AMP v2.3.2.4

Problem Description:
AMP Controller ignores configured target IP and just keeps trying to use the public hostname. Access from the server to the hostname is not possible. A direct connection using the supplied IP-Address during setup does work flawlessly, but after setup AMP completely refuses to use that and keeps trying to use the public hostname.

Steps to reproduce:

  • Set up AMP Controller on with open Port 8080
  • finish setup of AMP Controller
  • Set up AMP Target on with only LAN-Networking by design!
  • finish setup of Target over direct IP connection ( with controller on
  • Controller corrects the address to “hostname:8080” which yields a “connection refused” (because a route from the outside to the target is not intended!, Also not possible, because the public port is already in use by the controller)
  • Using the Edit dialog to manually change the address back to “saves” it, but does not use it and keeps reporting
Authentication Failure

Could not connect to the remote instance at http://<hostname>:8081/. Connection Refused

Please check configuration

I also have no idea, where the 8081 originates!

Actions taken to resolve so far:

  • Be thoroughly confused what the hack is going on.
  • Attempt NAT to forward public 8081 to internal, but that does also not work, because internal connections are not NATed, but instead faceplant on the Public Host.

Additional Information:

  • The AMP Controller is accessible from the outside using the given Hostname, the AMP Target is not! (except for when using the aforementioned NAT passthrough)
  • Reasons for this layout include isolation between instances for performance and security, simple changing of ‘physical computer’ for a service, by just switching the NAT mapping on the Public Host.
  • (Security: We are quite a large group, because we are eSports Group at our university. There are 3 People that are trusted with the entire server-network, but we have several ‘community admins’, that are responsible only for a single server each. Those community admins are not allowed access to the other servers, to prevent a single person from screwing up the entire group (happened in the past unfortunately). The Sub-Servers are managed, so we can easily take backups and deploy them to a different Sub-Server depending on required performance needs or in case of a bad change to an instance. Obviously with only 3 people it would be quite hard to manage all instances by ourselves and studying concurrently and working concurrently as well. University also means, that community admins change frequently.)


Changing how AMP connects to itself is more involved than changing a setting. If you’ve made a change you should use ampinstmgr repairauth and provide it the URL that should be used to access the controller. You’ll need to do this on the controller and on each target.

OK, while this did work somewhat, I didn’t make a change to the setup, this was a fresh install.

Additionally an interesting additional bug came up by this:

  • Managing an instance from the controller works
  • Clicking Manage on a target first and then trying to manage that same Instance yields “ADS failed to provide a login token.”

It’s a known issue, officially right now only controllers can manage instances.