Hi Guys,
If i wanted a fail over relay on another port like 80 or 443 in case a subnet can’t reach 52311. Is that doable? I looked at the BESRELAY.config file and saw nothing about port number. Does anyone know different?
Peter
I’m not sure if this is the only place it would need to be changed, but there are these client settings:
_BESRelay_HTTPServer_PortNumber
_Enterprise Server_ClientRegister_UDPMessagePort
Also, this is an interesting idea if it works.
The port MUST be the same across the deployment. The port is enforced by the masthead
1 Like
Would BigFix work if it was defined to use 443 from the beginning?
I don’t see why not. When it starts it would lock down that port if it was available but I think the clients, using the same masthead, would also use 443 meaning no other application could use it. That sounds problematic.
Hi guys,
I tested it with port 80 and it worked it registered with that relay and I was able to switch it to a 52311 relay without issue.
Thanks,
Peter
1 Like
It would be the relays and the root server that could not use port 443 for other things, but the clients could. Clients connect to many different servers over 443 all the time every day.
I don’t think there is any reason that you would need 443 to be available on a root server or relay unless you are trying to put a relay or root on a server that is already being used as a webserver, which is a bad idea anyway.
The Client listening to UDP packets on 443 might be an issue, so that might be better on the default port.
I would think it would only be the root server’s port that would be enforced by the masthead, not the relays.
If this does work without issue, then I think all deployments should have at least one relay with a port that is either 80 or 443 just so that clients with restrictive outbound firewalls could report in, particularly for an internet facing relay.
For this proposed relay using 443, I would give it an affiliation group that no client has so that it will not be apart of the * pool of relays, and then set it up as the failover relay. ( We use automatic relay selection everywhere ) With this configuration it should only ever be used by clients that fail all other relay selection, which would be a good indicator that those clients are having an issue with the other ports.
Hi JGSTEW,
Yes I agreed that is our plan. You can tell people to open ports but then it’s a big job to trackdown and confirm that it’s not open if I atleast can hit the machine from a 80 or 443 relay then I can test from the endpoint and confirm the port is closed or blocked.
Thanks,
Peter
1 Like
You may need command polling on any clients using that relay. We now set command polling to at least once every 12 hours on all clients automatically, both through clientsettings.cfg and a task that all clients run at least once as an open action.
I have tasks to set command polling to be more aggressive for clients not receiving UDP packets.
http://bigfix.me/fixlet/details/3942 (I see this one needs the minimum report time adjusted to 90 seconds)
http://bigfix.me/fixlet/details/3798
http://bigfix.me/fixlet/details/3801
http://bigfix.me/fixlet/details/3799
I am told that command polling primarily causes extra load on relays, not the root server. We are far more concerned with load on our root than our relays.
The masthead is supposed to be the defacto port list. I’ll check in the code but its supposed to enforce this on every endpoint. If you change it on a relay how will a client know how to find it as the client will use the port in the masthead to communicate with the relay.
The client would have it defined as it’s failover relay:
_BESClient_RelaySelect_FailoverRelay =
http://RELAY.DOMAIN.TLD:443/bfmirror/downloads/
Also, when the client gets the list of relays in an affiliation group, perhaps that would include the port number?
Client setting point to failover relay without :52311 works fine and when I repointed it to a 52311 relay it worked fine. FYI using http with no :52311 worked fine and I’m sure using https or :443 will work. If they fail that far I will build an action to check the port to a known listening 52311 and only switch if successful and flag it if it can’t phone home on 52311.
1 Like
Our current failover relay is defined like this:
http://RELAY.DOMAIN.TLD:52311/bfmirror/downloads/
… so since that includes the port, I figure it might work if the port was different.
I don’t know why you would do this, but since it seems to be HTTP traffic, I wonder if a client could talk to a relay through a reverse proxy? (ICMP probably wouldn’t work)
Not really sure if that works. The other issue is if a parent relay can’t reach the relay (its going to try to find it on the deployment port) it won’t receive notifications.
Hi Alan,
I’m positive using client settings with the last relay being on port 80 worked flawlessly. I pushed actions to it talking on port 80 and that port 80 was using a52311 relay as its relay. Sure it might have been slower than a udp action but within 15 minutes it processed. The whole purpose is to retain some method of communication to the endpoint. Any machine talking to this relay has issues but at least I can get access to it even if it’s on a remote network I don’t have credentials or access to. At this point I can troubleshoot why it wouldn’t talk to a 52311 relay and once the issue is resolved I can point it back.
Peter
I believe Alan’s most recent response was specifically about my wondering about using a reverse proxy.
@jgstew - if you’re using enhanced security you can’t go through a reverse proxy, the client authentication will fail.
With enhanced security off you can have a client go to a relay via a virtual IP and also have port translation.
1 Like
It would be nice to have all of these possible configurations for relays documented in which situations they will work or not and any potential issues and the degree to which they are considered “supported”. Seems like there are quite a few possibilities.