Effective use of the x-bes-fallback-server setting

Usage and Config
1

I am trying to better understand the usage of the x-bes-fallback-server masthead setting. The HCL BigFix documentation is as follows:

Last fallback Relay for all clients (replacing Root Server):
You might need to define a fallback relay for your clients when they do not connect to any relay specified in their settings. Select this check box and specify the fallback relay of your environment in one of the following formats:

  • Hostname. For example, myhostname.
  • Fully qualified domain name (FQDN). For example, myhostname.mydomain.com.
  • IP address. For example, 10.10.10.10.

If you do not select this check box and define a fallback relay, the root server of your environment is used.

Note: Before specifying a fallback relay, ensure that any client or relay reporting directly to the root server has the root server defined as a relay. This setting will not prevent endpoints from selecting the root server. Set _BESRelay_Register_Affiliation_AdvertisementList on the BES Root Server to a group name that will not be set on any clients, such as DoNotSelectMe.

This leaves me with lots of questions…

Our current masthead contains a valid x-bes-fallback-server defined, but is that all that’s necessary? The documentation above states that “This setting will not prevent endpoints from selecting the root server.” If this is not done, is there any point to the setting? Is the Root server still considered a valid relay unless it is added to an Affiliation AdvertisementList? What about if the server’s port 52311 was block to all but Relay servers?

If a new client installation has a masthead with x-bes-fallback-server defined, what exactly happens? If the Fallback Server is an authenticating relay, will a brand new client still be able to connect to the Root Server to get the necessary singing keys?

How is this setting best used? The documentation leave a lot to be figured out, IMHO… (or, is there better documentation on the setting? A wiki article or blog post? My Google-fu may have been weak today…)

2

I’ll do my best to provide as much information as I can. I implemented it during our BigFix Infra migration.

No, having a valid x-bes-fallback-server defined in your masthead isn’t the only factor however its indeed an essential component that ensure a robust fallback mechanism that enhances the reliability and availability of your BigFix infrastructure.

That is accurate, indeed! When I set up the fallback relay, the client could not reach it and began contacting the root server because of a DNS rollback. The goal is to build a reliable failover that clients can access in the event that the relay or root server is unavailable.

The main advantage, as far as I can tell, is that it’s integrated into your BESClient masthead. If you haven’t configured any failover settings or any failover policy setting action hasn’t reached the client, then the client has a direct option for failover.

I experienced a similar type of behaviour when I wanted to use Relay Affiliation to forcefully assign specific relays to specific clients, but it would not work if ICMP and Distance were not in the client’s favour. Regardless of whether the root server is added or not added in the Affiliation AdvertisementList, the client will still select it based on the infrastructure configurations. There are situations where the client chooses other relays that are significantly farther away from the nearest ICMP and relay, even though it is the closest one.

Indeed, that’s the part that always works. In that scenario, clients won’t be able to connect to the root server, and in my opinion, that’s the best way to keep the root server free from unhappy clients.

Yes, in the event that the client is not set up with a secure registration password, the password is entered incorrectly, or the fallback relay is unable to authenticate for any reason, the client will connect to the root server.

As previously mentioned, the x-bes-fallback-server setting serves as a component of a robust failover mechanism. However, it’s essential to consider other critical settings, such as relay configurations, failover relay lists, and overall infrastructure design, when configuring a comprehensive failover process. These factors collectively contribute to the resilience and effectiveness of the failover strategy within the BigFix environment.

I’ve done my best, but I’m still learning in the BigFix academy! :blush: There are some real experts out there like @JasonWalker, @jgstew, @brolly33 who can shed more light on this.

3 Likes
3

I believe you can set the root server to not be auto selectable and also have it advertise an auto selection group that is not used.

_BESRelay_Selection_AutoSelectableRelay=0

that is an option, but that might orphan some bigfix clients that are not behaving.

Your fallback server should not be authenticating if you want to support the install of new clients without providing a relay auth password to allow it to register for the first time.

In a sense, the fallback server is equivalent to the root as far as the client is concerned when it fails automatic and failover relay selection and has to resort to using the relay defined in the masthead, which would usually be the root, but when you have this setting configured, it is now whatever you have it configured to.

The x-bes-fallback-server configured in the masthead should be a DNS CNAME that you can point to anything you want and you could even point it to one relay inside your network and a different relay outside your network on the public internet such that it resolves a non authenticating relay inside the network and an authenticating DMZ relay outside your network. If you do this, I would probably still recommend having a different DMZ relay as the primary, and the one setup this way only for clients that end up selecting based upon the masthead.

Basically I would generally also have x-bes-fallback-server that is resolved not be auto selectable so that you know any client talking to it is doing so because it has no other option.

1 Like
4

This is what we currently have in place, but I don’t believe we have any other related settings (e.g. _BESRelay_Selection_AutoSelectableRelay=0 on the root) to prevent the selection of the root server in the first place. That was the basic gist of my question: other than a resource if the root server is unreachable, is there an use to just having a failover server defined, or is it only truly useful for protecting the root server when used in conjunction with other settings, like AutoSelectableRelay=0 or firewall blocking. I get the sense that the answer is “no, there is no root server protection in the fallback server setting without making the root server non-selectable”.

Am I reading your comments correctly in this regard?

5

With the exception of our root server and a single local network failover server, all of our relays are DMZ (authenticating) relays. :open_mouth: We’ve got way too many people operating off the local network, nowadays.

1 Like
6

The purpose of the setting is to prevent clients who have no alternative from selecting the root server, but if all clients are using automatic relay selection the root server is by default an auto selectable relay ( unless _BESRelay_Selection_AutoSelectableRelay=0 ), so if you aren’t using relay affiliation groups, it will get selected sometimes.

So in a sense, use of x-bes-fallback-server does prevent clients that failed auto selection from selecting the root, but not clients that succeed in auto selection, but in the process select the root as the best auto selectable relay.

You should only have to block ICMP traffic from clients to the root to prevent it from being auto selected, not 52311 traffic, but you could/should use _BESRelay_Selection_AutoSelectableRelay=0 on the root if that is your intent.

All that said, I’m not 100% sure if that setting is effective on the root or not, lol. Some settings the root will ignore because it is “special”.

7

I thought I remembered reading somewhere that it was not, hence the “null” relay affiliation group or firewall options.

1 Like
8

I think this is what I needed to hear. The “fallback server” masthead setting has nothing to do with protecting the root server and will not do so. Rather, it’s where computers look instead of the root server if they can’t find anything else. If the desire is to protect the root server, either AutoSelectableRelay=0, a null affiliation group, or firewall blocks (not recommended) are necessary.

Is that accurate?

9

Hmm, that might be the case. I do see my root server in my Relays.dat file when I parse it.

That might explain why I have the following set on my root server:

_BESRelay_Register_Affiliation_AdvertisementList=FakeAffiliationRootServer

I do not really understand why you can’t exclude it from being auto selectable. ( I realize it would still be manually selectable, which is what masthead fallback would be )

This seems like a bad idea, but you could perhaps set:

_BESClient_Relay_NameOverride=0.0.0.0 on the root which should control how it shows up in Relays.dat

1 Like
10

Oh, you can also set the relay priority and weight, and that does work for the root server.

_BESRelay_Selection_RelayPriority=10000

and

_BESRelay_Selection_RelayWeight=10000

11

I wouldn’t override the name, that makes Manual Selection problematic.
The root server does not respect the AutoselectableRelay setting so applying an unused AdvertisementList can be used to prevent clients from auto-selecting it.

The last-fallback-relay setting is intended for use instead of DNS manipulation to provide a “fake-root” setup.

1 Like
12

I thought the name override only applied to automatic selection? And how it shows up in Relays.dat ?

That said, I agree, it is a better idea to use these:

_BESRelay_Register_Affiliation_AdvertisementList=FakeAffiliationRootServer
_BESRelay_Selection_RelayPriority=10000
_BESRelay_Selection_RelayWeight=10000

on the root.

Thought my root seems to show Weight=0 in Relays.dat yet I don’t have that set anywhere… maybe that makes it selected last?

2 Likes