NAT in between master and agent, wrong IP address negotiated

Hello SoftTree Team,

We have two 24x7 Scheduler Multiplatform Edition v4.4 running on RedHat Enterprise Linux 6.5 and jdk1.6.0_31. One is running as master and one is running as agent. Connecting from master to agent requires going via a NAT router. Here is the simplified setup:

MASTER (192.168.10.10)
|
V
Request to 192.168.20.20 (Set as IP address in "Location:")
|
V
NAT router translates 192.168.20.20 to 192.168.30.30
|
V
AGENT (192.168.30.30)

When doing a "Test Connect..." ("Remote Host Profile Properties" window) we can see on the network of the master (before NAT) the following two TCP session requests:
192.168.10.10 -> 192.168.20.20 (TCP session established successful)
192.168.10.10 -> 192.168.30.30 (This session cannot be established)

It looks like within the first TCP session the agent tells the master the physical IP address of the server the agent is running on. In the above scenario this is 192.168.30.30 which is an address that the master cannot reach directly.

This behavior might be perfect in setups where you have multiple agents behind a load blancer and it is still possible to access each agent directly. But in our setup we are required to access the agent by the address 192.168.20.20, not the address the agent sends to master.

Is there a way to configure the behavior of the agent to _not_ send IP addresses the agent determines on his side?

Thanks in advance
Jorg

This sounds like a difficult case, the issue seems to be in limitations of Java RMI protocol, which is used internally. I'm not sure if it can be addressed by tweaking agent's configuration settings.

I suggest to figure out an alternative solution, for example running a scheduler not an agent and making it periodically check for jobs it needs to run. The main scheduler would set some flags(create semaphore files or update some data in a database, etc...) that would trigger those jobs

Thank you for the answer. We found out that the wrong IP address is determined with the hostname of the server running the agent. Like a 'nslookup' using the output of command 'hostname'. Maybe this is the key to solve the problem. Thanks again.