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 10.1.1.100 with open Port 8080
- finish setup of AMP Controller
- Set up AMP Target on 10.1.1.101 with only LAN-Networking by design!
- finish setup of Target over direct IP connection (10.1.1.101:8080 with controller on 10.1.1.100:8080)
- 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 http://10.1.1.101:8080 “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 10.1.1.101:8080, 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.)
Network-Layout:
