So this is a very unique installation which admittedly may not be the way most environments are set up, but I thought I’d bring it to the boards for feedback anyway.
Basically there is one company with two domains separated with firewalls. The BigFix server is on one domain and the idea is to setup a relay on the other domain to which clients on that side will report. The computer that will become the relay has been given access to the firewall to port 52311 on TCP/UDP.
-
From the second domain the BigFix server (in the first domain) has a NATted address (192.168.x.x)
-
When attempting to install the client on the relay box I get “Get URL failed (winsock 6)” errors.
-
There is a DNS entry that resolves the clients on domain 2 to the NATted address of the server which resides on domain 1.
If I enter the NATted IP address of the server into the BES Console I can login. If I enter the FQDN I can also login; however, the client is still unable to communicate even though the client can resolve the IP Address to the server (though it times out because ICMP is not allowed). – Using Manual Relay config.
The customer has put forth an idea to open port 53 from the DNS server on domain 2 and forward that DNS request to a DNS server on domain 1 (who should then be able to resolve the FQDN of the BigFix server)
Even if this resolves the issue for this specific client the concern is that none of the other clients we install will be able to be installed correctly because THEY will not be allowed to send traffic through the Firewall (on the relay computer).
I tend to think that once there is a ‘registration server’ (the relay) on domain 2 it will use it’s connection through to the DNS server in domain 1 to post its reports coming from endpoints. Am I doing a lot of firewall request work for nothing?
Ideas?
Thanks,
Mike
I think it may help to put some example names & IPs in here.
Suppose the bes server is “bes.domain1.com” with IP address 10.1.1.10. This is seen via NAT from domain2 as 192.168.2.10. You have the prospective “relay.domain2.com” with IP address 192.168.2.11.
When you say you have a DNS entry resolving to the NAT’d address - do you mean that there is an entry “bes.domain1.com”, resolved from domain2 - returns the NAT’d address 192.168.2.10 (using the same FQDN name as in the masthead), or that there is an entry for “bes.domain2.com” (because that wouldn’t work.)
Without ICMP communication, the client will not select a Relay (either Auto Select or Manual Select). The client would default to failing over to the root server specified in your masthead file when it cannot ping any relay. Referring to https://www.ibm.com/developerworks/community/wikis/home/wiki/Tivoli%20Endpoint%20Manager/page/Configuration%20Settings , you’d need to use either “_BESClient_RelaySelect_FailoverRelay” or “_BESClient_RelaySelect_FailoverRelayList” to direct the client to fail over to different relay(s).
I think the easiest thing to do in your scenario is for “relay.domain2.com” to either have a HOSTS file containing “bes.domain1.com” with the NAT’d address for the root server, or a “_BESClient_RelaySelect_FailoverRelay” client setting pointing to the NAT’d IP address of the root server (or other high-level relay). That should get the relay’s client communicating with the root. Then, have a DNS entry resolving on domain2, directing “bes.domain1.com” to the IP address of domain2’s Relay. When clients think they are communicating with “bes.domain1.com”, they’re actually registering / reporting through domain2’s relay.
You should still have the domain2 clients configured for automatic relay select, or manually configured for “relay.domain2.com” so that after their initial registration, they will report up the correct name for their selected relay (it makes the Relay computer property report correctly and helps in some dashboards). You’ll want the domain2 clients to be able to ping relay.domain2.com.
This should work as a classic fake-root configuration.