We have a relay that is on a segmented network, it has a NAT’d address.
The hostname of the relay is not resolvable from the BES server. The IP address that the relay presents to BigFix is obviously the real address, not the NAT address. The clients that use this relay are able to connect to it because they can resolve the name.
Both UDP & TCP/52311 is allowed from the network where the BES servers are to the relay’s network, and TCP/52311 is allowed back. However UDP is not making it to the relay.
What do I need to do to correct this, add a DNS record for the hostname resolving to the NAT address? Some changes on the relay?
The Relay to Server “relationship” should be resolved when the relay registers upstream. The server should “see” the outer IP of the relay, unlike the agents inside the NAT which will “see” the inner IP of the relay.
Note - Server to Relay and Relay to Relay gather notifications are on TCP. Only Relay to Client are UDP.
Not sure of the exact situation, but you might check also out name override setting to see if it helps?
_BESClient_Relay_NameOverride
The Relay to Server “relationship” should be resolved when the relay registers upstream. The server should “see” the outer IP of the relay, unlike the agents inside the NAT which will “see” the inner IP of the relay.
When I look at the relay’s Core Properties it shows the inner IP as the IP address, not the outer (NAT) address. Would it still be using the outer address but not shown?
Note - Server to Relay and Relay to Relay gather notifications are on TCP. Only Relay to Client are UDP.
Right. What I meant was I was sending a refresh command to the relay itself, that should have come from that relay’s relay as UDP, right?
The IP of the Relay according to the client on the Relay will indeed be the Inner IP.
Check the registration list on the BigFix server and I think you will see the Outer IP from the BigFix server Point of View.
Send Refresh to the Relay would come from the BigFix server (who will send the TCP to the OuterIP of the Relay according to Registration list on the BigFix server). That refresh would land on the BigFix Relay Service, who should be listening on the TCP port 52311. Once that arrives, the Relay should send a UDP to the Registration Address of the Client on that Relay. Since the client registers with it’s relay on loopback, that refresh should get to the relay’s client.
I hope that makes more sense to you than it does to me when I re-read it 3-4 times…
The magic happens during Client Registrations and lives the in the Registration Lists on the Server and downstream Relays. The Network translates the Inner to Outer based on what side the component is on. registration is a two way conversation, so both sides only know their side of the conversation and the NAT does the connection.
In other words,
The Registration List has: “from here, how do I reach this relay/client” information. (OuterIP)
The IP Address property in the console has: from local client point of view, what does the client think is the IP address. (InnerIP)
Each Relay also has its own registration database, which can be accessed via the SQLite family of inspectors in the Fixlet debugger or in qna.exe. I should be able to post an example tomorrow to have the Top-Level Relay report the “next hop” to the Child Relay.
Notifications for new actions/content would be a TCP connect from the parent relay to the child relay.
You may run this query through the Fixlet Debugger, the BigFix Query app, or the qna.exe or qna binary on the Parent Relay to see details of the child relays registered to it.
q: rows of statement ("select ComputerID,ParentID,IsRelay,IPAddress,PersistentIPAddress FROM COMPUTER_REGISTRATIONS WHERE IsRelay = 1 LIMIT 10 ") of sqlite database of files "ClientRegisterData/registrationlist.db" of parent folder of folder (value of setting "_BESRelay_HTTPServer_ServerRootPath" of client as string)
What I think we’re expecting to see is the “IPAddress” field return the public address of the client the way that the parent relay sees it, and the “PersistentIPAddress” field to return the relay’s locally-visible address.
So when downstream notifications happen to Client,
Root @ 1.1.1.1 sends traffic to TLR at 5.5.5.5 (as defined in the DB on Root server)
5.5.5.5 gets NAT into 6.6.6.6
TLR @ 6.6.6.6 sends traffic to SR @ 10.10.10.10 (as defined in the DB on the TLR)
10.10.10.10 gets NAT into 20.20.20.20
SR @ 20.20.20.20 sends traffic to Client @ 20.20.20.21 (as defined in DB on the SR)
SR is on LAN with client, so the actual IP are used. (NAT not involved, but it could be… the model still works)
Tracing back upstream,
client @ 20.20.20.21 sends report to SR @ 20.20.20.20 (noNAT)
SR @ 20.20.20.20 sends report to TLR @ 6.6.6.6 (outer NAT of TLR)
TLR @ 5.5.5.5 sends report to Root @ 1.1.1.1 (outer NAT of root… real IP might be different inside the NAT)
Each component knows the upstream and downstream items from it’s point of view with regards to the NAT.
q: rows of statement ("select ComputerID,ParentID,IsRelay,IPAddress,PersistentIPAddress FROM COMPUTER_REGISTRATIONS WHERE IsRelay = 1 LIMIT 10 ") of sqlite database of files “ClientRegisterData/registrationlist.db” of parent folder of folder (value of setting “_BESRelay_HTTPServer_ServerRootPath” of client as string)
This had me scratching my head this morning. On the top-level relay for Europe I was seeing only the relays for North America and couldn’t figure out why I wasn’t seeing others. Then I saw the “LIMIT 10” statement. It’s too early for this!
But anyway… The NAT’d relay is showing the NAT (public) address and not the local address.
To summarize:
I thought it was an issue that UDP wasn’t making it from the top-level relay to the NAT’d relay, that is not an issue because it’d come from the relay process running on the NAT’d relay itself.
The NAT’d relay is reporting the public address to the top-level relay, the top-level relay will use that for communication.
