Agent behind a NAT
Yet another scenario involving NATed environments is when the system on which the agent is installed is also behind a network address translator (see Figure 1). Suppose that the agent is being installed on a server with a private IP address 192.168.10.7, and that this agent has to be configured to communicate with the manager on 10.5.20.12 (which is accessible over the Internet as 209.15.165.127). Suppose that the private IP 192.168.10.7 is translated into the public IP address 209.15.2.3 via a NAT (see Figure 1).
In this case:
- When installing the agent, the address of the manager to which the agent must communicate has to be specified as its public IP - i.e., 209.15.165.127.
- On the manager side, the “authentication” setting in the Agents->Settings->Communication Menu has to be set to “Off”. This is because the private IP address 192.168.10.7 is not accessible to the eG manager (which is actually running on a different Intranet with IP 10.5.20.12). Hence, the manager cannot check the validity of the agent’s IP address directly.
- When managing the server via the eG admin interface, the server’s IP address must be specified as 192.168.10.7. To see why this is the case, consider how the agent/manager communication works. When the agent connects to the manager, it presents its identity - IP address, nick names, hostname, etc. The manager determines the tests that must be executed by the agent based on its identity and passes this information back to the agent. In this case, the NATed public IP of the agent system (209.15.2.3) is NOT known to the agent (as this is not explicitly configured on the agent system). Hence, servers/applications on the target system must be managed using the private IP address (i.e., 192.168.10.7).
Although the above scenario has been described in the context of a NATed environment, the same steps above apply if the agent is communicating to the manager using a proxy server as well.
