I’m trying to use the value from registration subnet address of client to use in a custom fixlet that designates relay mode and assignment of relays or relay affiliation tags from a single CSV file from a custom site. Works great… However, a few endpoints error on evaluation with singular expression refers to a nonexistent object The hosts it fails on are RHEL 6 and MacOS. Works fine on windows (several variants) and SuSE. Registration CIDR and registration address also fail with the same error. Each of the failing endpoints have only one NIC and one IP address. The RHEL endpoints is on the same subnet as the BigFix Server. Haven’t been able to find anything other than dead ends on this.
Anyone have any thoughts on why this fails with these OS’s?
If you have a machine that is behind a NAT or the IP address the relay/server gets doesn’t match any of the registration IP addresses that the client sends up in its registration request, there are a few inspectors that will not have a value to return as the server has no idea what the actual IP address is.
Think of a case like this. Client is behind NAT and uses 10.1.1.1 as its address and then registers with a relay on the other side of its NAT and thus it uses the router/NAT address which is 192.168.1.10 so the infrastructure thinks it registered as that address. The Client used 10.1.1.1 on its registration but as that’s not an IP address that matches what the client actually came in on the reply to the registration is not able to give back the address that was registered on.
This inspector is supposed to be able to help distinguish which of the 10 NIC’s you have did you actually register over but it depends on the receiving end (the relay) being able to give an IP address it is communicating over to the server that matches the registration request.
Do any of these scenarios apply in your case? It doesn’t seem to be if they are on the same subnet unless there is some strange routing going on.
I’d look at your logs as to what the information going up in the registration command is as if that information isn’t valid its possible that the endpoint has some strange configuration that doesn’t match the reality of the network.
None of those situations apply. Using IPv4 (IPv6 disabled) and issue is not NAT related. The RHEL endpoint is on the SAME subnet 10.0.0.0/24 as the BigFix Server. The MacOS endpoint IS behind NAT but all of the other windows systems on the same subnet do not have a problem resolving the query. So lets ignore the MacOS system for now… Why would the RHEL agent error on the same subnet as the BigFix server (and registered directly with the server)? Thoughts?
Re-read your post… registration commands from log:
SuSE:
RegisterOnce: Attempting secure registration with 'https://bigfix.xxx.com:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=9.2.6.94&Body=1977471&SequenceNumber=12&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://bigfix.xxx.com%3a52311&AdapterInfo=0a-00-5e-e3-d0-d9_10.0.0.0%2f24_10.0.0.104_0'
Registration Server version 9.2.6.94 , Relay version 9.2.6.94
RHEL:
At 10:40:52 -0500 -
RegisterOnce: Attempting secure registration with 'https://bigfix.xxx.com:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=9.2.6.94&Body=6182350&SequenceNumber=44&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://bigfix.xxx2311&AdapterInfo=0a-6d-30-6f-68-96_10.0.0.0%2f24_10.0.0.150_0&AdapterIpv6=0a-6d-30-6f-68-96%5efe80%3a%3a86d%3a30ff%3afe6f%3a6896%2f64_0'
Unrestricted mode
Configuring listener without wake-on-lan
Registered with url 'https://bigfix.xxx.com:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=9.2.6.94&Body=6182350&SequenceNumber=44&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&Root=http://bigfix.xxx.com%3a52311&AdapterInfo=0a-6d-30-6f-68-96_10.0.0.0%2f24_10.0.0.150_0&AdapterIpv6=0a-6d-30-6f-68-96%5efe80%3a%3a86d%3a30ff%3afe6f%3a6896%2f64_0'
Registration Server version 9.2.6.94 , Relay version 9.2.6.94
yep… disabling IPv6 fixed it… but looking at the inspectors (linked above):
registration subnet address of
Plural: registration subnet addresses This Inspector returns the subnet address (as an type) from the adapter that the specified BigFix client registered with.
Both the IPV4 and IPV6 are handled internally in the same structure so it should handle this fine.
The answer for this inspector comes back in the registration interaction for the client so if the server didn’t send it then we have nothing to answer with. It should give back the information that was presented to the relay.
The following line
Configuring listener without wake-on-lan
is often a sign that something is a bit confusing to the agent and its usually when I see this message that there is an issue with the registration address inspectors. I do notice that the subnet masks are different between the two machines which possibly could have some influence?
Running the QnA tool on a win10 system, I can enable / disable IPv6 and watch the relevance fail / work respectively. I do have to restart the client each time for it to toggle behavior, but the “configuring listener without wake-on-lan” is there both with and without IPv6.
Subnet masks are /24 across the board (client / relay / server), so not sure what you mean by that?
FWIW, what I’ve discovered after extensive testing is:
No NAT / IPv6 Disabled - OK
No NAT / IPv6 Enabled - OK
NAT / IPv6 Disabled - OK
NAT / IPv6 Enabled - FAILS
So there is a client setting to make the client prefer the IPV4 connection over the IPV6 though that is the “default” behaviour, does this help it at all?
_BESClient_Comm_IPCommunicationsMode
Type: String
Version: 8.0
Platform: All
Default: Ipv4ThenIpv6
Requires Client Restart: NO
Description: Selects the preference of network topology from the set ("Ipv4ThenIpv6", "Ipv6ThenIpv4", "OnlyIpv4")