We are installing a child relay behind a NAT and I wanted to check for any considerations. I understand the parent relay sends notifications to the child via a TCP connect. Does the parent determine child relay IP address from its client reported IP address, or by resolving its hostname, or by checking source address from the child’s previous upstream connect?
I’m not sure the relay name override would be effective, as the upstream relay will need to connect to its public address, but all of the child relay’s clients will need to use its private address.
So, from my testing thus far, it looks like with a static NAT it “just works”. I changed the child relay from a hide NAT to a static NAT, restarted the relay & client services. Then the parent relay sends child relay notifications on 52311/tcp to the public address of the child relay, the child relay receives it, and everything is reporting back in a timely manner.
It looks like DNS name resolution of the child relay, and the child relay’s reported IP address (which is still the private IP), are not involved at all.
Hi, so you’re saying the BigFix infrastructure becomes aware of the “external” IP of the relay that is behind the NAT and is able to communicate with that child relay behind NAT on TCP 52311?
With a static NAT, yes that’s been my experience. It appears that when the child relay (behind NAT) contacts the upstream relay, the upstream relay records the source IP address and uses that when contacting the child relay. It doesn’t look like the parent relay is using DNS to resolve the child relay’s IP address. So with a Static (not Hide) NAT, it just works.
But how does that work? The source IP of the NAT’ed Relay would not be known the the parent Relay. Do you mean the parent Relay identifies the external IP of the NAT’ed Relay and uses that for communications? Because if so, that would be great.
That’s my guess, I don’t work for IBM and don’t have access to the code. Just relating my experience.
When a child relay makes a connection to a parent relay, the parent relay would know the source IP address of the incoming connection (which would be the NAT’d/public address of the child relay). It’s possible that the parent relay records this address in it’s list of registered child objects and sends downstream notifications for new content based on this recorded address. The behavior I’m seeing implies that this is the case, because the downstream notifications are working and I didn’t do any special games with DNS or hosts file masquerading for the public IP address of the child relay.
I don’t know, but the parent relay definitely gets the external IP of the NAT when the child relay connects through the NAT, so I’m assuming it uses that IP to communicate with the child relay. I’m not saying this based upon any knowledge of how BigFix works, just how NAT generally works.
I was under the impression the BigFix Relays would only know of the Relay’s IP that the BES Client detects from the OS and know nothing about the external NAT IP…
The Parent Relay shouldn’t be contacting the Child Relay at all. The connections go up the tree, not downward.
A Relay sends a notification to child nodes (and maybe child relays?) in its registration list with a 52311/UDP packet. But that’s not based on resolving the child hostnames, it’s based on the child having recently registered to the relay.
Isn’t every time there a change to a site the BES Root propagates a new site to all the “Parent” relays and in turn to their Child Relays by the Root server starting that TCP 52311 connection? Then the next level Parent Relays initiate a connect to their child Relays and so on?
When there’s a new Site, the Root sends a UDP notification to its registered children (those who have checked in recently, clients (and maybe Relays)). Each Relay will in turn send a UDP notification to its registered clients / child relays.
When the child node sees the UDP notification, the child does a TCP connect to its parent and downloads the new site.
The child nodes/relays will initiate a TCP connection and check for new sites periodically even if they receive no UDP notifications. I believe the default on that is every 12 hours. You can set up the Command Polling parameters to perform this gather more frequently, in cases where the child node/relay is not going to be able to receive the UDP notifications due to firewall rules or Hide NAT or something along those lines.
My understanding is that the relays all communicate over TCP and not UDP
The child relay should be able to establish the TCP connection with the parent from behind the NAT. When this happens, the parent relay sees the NAT’s external IP but coming from a port that the NAT knows maps to the child relay, so then the NAT knows to send traffic over that TCP connection from the parent relay to the child relay.
UDP should not be able to transit a NAT without static port mapping because it is stateless, but TCP can transit the NAT if it originates from behind the NAT.
Client’s don’t need to talk to the root server directly at all, especially if using a clientsettings.cfg file when installing the client, or by using Fake Root where a relay is contacted by clients that think they are talking to the root server.
Essentially, Clients need to know how to talk to a relay, or if they don’t know about any relays, then they will failover to talking to the root server FQDN in the masthead file since they don’t know about anything else at that point. You can point that FQDN in the masthead at a relay in DNS instead of the root and make the root inaccessible to the clients.
for our deployment, we currently don’t use a “fake root server” and the fqdn in the masthead is a cname for our bes root server. That way i don’t need to provide a custom installer with a clientsettings.cfg file (unless a device can’t reach the root server).
However, I need to re-IP our root server so I was thinking that for a long term solution, it would be better that it is behind a VIP so that the same external VIP IP can be used for firewalls/routing. I just was unsure if there are any gotcha’s with having the root server behind a VIP, client source IP masking.
.
the root server’s IP address can change as much as you want without any issue as long as the CNAME record ultimately resolves as the root server’s IP in the masthead.
Clients and top level relays trying to talk to the root may have trouble for a little bit while DNS updates, but you can adjust your TTL to be lower before you reip.
You could also consider pointing the CNAME in the masthead to a relay, then the root server doesn’t factor in. Just make sure the relay that you point that masthead to knows to talk to the root servers real DNS name before trying the one in the masthead, which would be itself.