I recently installed a couple of internet facing relays and I’m having a but of an issue and I want to understand client behavior for when it does a relay selection.
The client, from the internet, realizes it’s unable to contact the internal network relays.
It runs a relay selection by going through it’s relay affiliation list to find its closest relay
If the external relays do not respond to a ping because it’s not open on the external firewall. I assume this means the client will not attempt to register to the external relays? The idea is that most of the laptops that are external should have the updated settings to know to try to talk to the external facing relays but the log does not indicate it tried to even though it’s in the affiliation list.
How does a client determine if its relay is in the affiliation list? Is it written in the masthead or supporting data files? If it is, why does it not attempt to contact the server or does it just not log the attempt if it can’t ping it?
In manual relay selection, the BES Client sends an ICMP packet at the Maximum TTL to BES Relays prior to attempting registration. If the ICMP does not reach a BES Relay the BES Client will not attempt to register with it. If the ICMP ping is successful and the BES Client registers with the BES Relay the hop count determined by the ICMP packet is reported in the Distance to BES Relay property.
During automatic relay selection, the BES Client sends out rounds of ICMP traffic with a constant TTL in each round. Each round of will send an ICMP packet to every BES Relay (BES Relays are listed in the ActionSite’s Relay.dat file). Each round will each use a TTL at a higher value then the previous round, starting at 0 and skipping values at higher TTL values.
This is the most useful post i’ve found regarding troubleshooting relay selection:
So ICMP traffic also needs to be allowed on the external firewall? I’m not really a network guy and I don’t modify the network at any level so I want to get my request for the opening of necessary ports correct without opening us up to any additional risk.
I ask because the line in the documentation states it “can aid” but that it’s not required:
After relay communication is established between the DMZ and the internal corporate network, the external firewall also has to be opened to allow Internet-based client traffic (HTTP port 52311) to reach the DMZ relay. In addition, allowing ICMP traffic through the external firewall to the Internet-facing relay can aid in the external client auto-relay selection process.
So when it says “HTTP port 52311”, does that encompass TCP and ICMP?
Relay Auto selection is definitely a bit confusing to me at times.
In many cases more clients will end up talking to older relays rather than newer ones. This might be because they prefer to talk to their previous relay, or maybe because they don’t “Know” about the new ones yet.
I do think ICMP is generally required for Relay Auto selection, but you can set a Failover Relay on all clients. They will try the Failover Relay before trying the root once auto selection fails.
It is probably not a bad idea to see about opening Ping traffic to your internet facing relays.
We opened up echo response which gets the desired effect without letting the whole ICMP suite through. I will try the failover relay setting on our test laptop and see if it helps as well.
It occurs to me that tracert might be required as well as they choose which relay to connect to based on hops. Without a successful tracert, won’t it assume it can’t reach it even though it can ping?
I think ping is most important, but yes, I’d think tracert is what it would use to try to determine which relay to choose, otherwise it would probably choose based upon affiliation group, weight, and randomness.
I have confirmed it is not necessary. All that is necessary is the echo request. Once we enabled that, laptops started reporting.
For people looking to implement an internet relay using automatic relay selection, here are the steps I took to complete this:
Configure my relay(s) to broadcast the internet address. This could be different than the IP address assigned to the local NIC due to NAT policies within your company. Consult your local network administrators for assistance on this.
Assign the relay(s) with a relay affiliation "__BESClientRegister_Affiliation_AdvertisementList"setting. In my case, the relays were in our DMZ so my affiliation group is respectively called “DMZ”
Configure any clients that may need to report to the relay(s) using the “_BESClient_Register_Affiliation_SeekList” setting to contain the “DMZ” group
Configure any clients that may need to report to the relay(s) with command polling. The length of time between polls is up to you but UDP pings to tell clients of new content will likely not reach outside agents.
On your external firewall (the one between your DMZ and the internet), open the TCP port that your IEM configuration uses TO your DMZ relay(s) only. Only traffic coming to the relay is required because a relay will never have to reach out to a client on the internet. The relay only serves as a point of contact for external agents to come update content. The agent will take care of the rest once it’s gotten it’s instructions.
An additional note: Because traffic between the clients and server is, by default, not encrypted, I would recommend enabling message level encryption. See here.
The settings discussed by @jgstew can be useful but, as I’ve learned, are not necessary or at least not necessary in my deployment. As long as your clients have an updated “Relays.dat” file which is part of the actionsite, and the client is configured to look for those relays, your clients should connect to them.
It will ping (I believe) each relay with increasing TTL until it determines the number of hops away the relay is. Clients will choose a relay in the affiliation group that is the lowest number of hops away.
@jmaple – Make sure you also disable the relay diagnostics page: __BESRelay_Diagnostics_Enable = 0
Enabling client authentications for the relays is a good idea too!
I would add that the clients should have “DMZ” as the last affiliation group in their seeklist so that they try those relays last.
I would recommend ALL clients use command polling of at least once every 6 or 12 hours, more often for mobile devices. This should be set in the clientsettings.cfg file used along side the installer, among other settings to kickstart the client. I would actually recommend that the setting in the cfg file be for command polling every hour and have an open action that will automatically reduce the command polling interval if the client is getting UDP notifications and the client has been installed for 3 or so days.
It is also a good idea to use the failover relay setting with one of your DMZ relays in the clientsettings.cfg file for the sake of clients that are installed remotely and do not get an updated “Relays.dat” right away.
Also, if you enable client authentication, you can put a password setting in your clientsettings.cfg file so that clients outside your network that get the client installed the first time can get through.
I would recommend setting message level encryption to optional for pretty much everyone. Clients will use encryption when they can, which should be all of the time, but they will failover to unencrypted. Do this at first until you can track down any issues. If message level encryption is set to enabled/required, then clients that for some reason cannot encrypt will not send any reports at all. They will still process actions, but you will never know the result of those actions.
Have you found any good documentation for client authentication (specifically the password you mention)? I haven’t been able to identify any documentation that outlines client auth…
Client Auth is a per-relay setting. You can require it on your DMZ relays but not require it on your non-DMZ relays.
When a client is installed for the first time, it must connect to a relay that does not require Client Auth, or it must have a password that gives it an exception.
Once this first connection is made, the client receives a certificate to allow it to do proper client auth from then on. I believe it is client side SSL.
I’m not sure where exactly I stumbled upon the client setting for a password to have the client get through Client Auth the first time around. It had to be in a support article or the Knowledge Center somewhere. I believe that the password must be set on both the relays and the clients for it to work.
It mentions the passwords being a one time thing. Not sure if you can have a standard password that is the same that would be put in a clientsettings.cfg file that everyone would use.
Hey @jgstew do you know the exact setting on the clientsettings.cfg to authenticate against an authenticating relay? i couldnt find any. We have several servers outside our network that we want to on-board with clientsettings.cfg through a DMZ authenticating relay.
Authenticating relays require the certificate for the relay be cached on the client before authentication is possible. If you read the documentation about authenticating relays there is an area that describes what clients need in order to get to an authenticating relay for he first time.
If I remember correctly, your clients would need to either first connect to your core server to get the required certificate or already have the certificate in order to connect to the relay.
EDIT: My mistake. I was referring the last link @jgstew posted.
Hmm… so no alternative through a password? How do you guys manage AWS instances as an example? If not on an IPSEC tunnel, my only option would be to create an non-authenticating relay in the DMZ…scary
