There is a scenario that can occur - although potentially "not that often" - but likely to increase as IPv6 becomes more widely adopted and people struggle to successfully configure it that can mean you can end up with a scenario where:
a) Bomgar Appliance has both IPv4 and IPv6 Addressing
b) The internet connection used by either a Jump Client or a Rep Console has both IPv4 and IPv6 under normal conditions
For some reason, a device - running either Rep Console OR Jump Client - ends up with broken IPv6 but working IPv4. Most likely if the IPv6 is statically configured (for example on a Windows Server) - rather than SLAAC or DHCPv6/DHCPv6-PD or ULA.
In that case, Bomgar Rep Console AND/OR Bomgar Jump Client does not have a mechanism that means it tries IPv6 (assuming the device is configured to prefer that - default in Windows for example), and if it cannot reach the support site/appliance tries again using the v4 address returned in DNS - and as a result, either a Rep cannot reconnect until they disable v6 - or a Jump Client cannot be reached (won't show online, cannot start sessions etc) until the v6 connectivity is restored working or IPv6 is disabled/removed (or for non-static assignments leases expire on DHCPv6 or SLAAC/ULA lifetimes/routes are removed).
As in Remote Support scenarios you can end up with that exact scenario by nature of why you might be providing Remote Support in the first place, having Bomgar intelligently work around it/try both protocols would be sensible and valuable.
I've validated this a few times now - it copes fine if IPv6 is completely removed, but where it is broken you also lose Bomgar service/access.
|Submitter Name||Vincent Paul Wilton|