Product Ideas Portal

Got an idea for a new feature? Maybe a tweak to make something work even better? Wish there was an integration with another product to make you even more productive? You've come to the right place.

The Product Ideas Portal lets you submit whatever product feedback you have, good, bad, ugly, and anywhere between.

Want to stay anonymous? No problem, you can still share your ideas with us. You can also create an account which lets you vote on other people's ideas and receive updates when your idea's status changes.

To learn more about how an idea becomes a feature, check out this infographic.


IPv6/IPv4 Fallback on JumpClient and Rep Console

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.

  • Vince Wilton
  • Dec 5 2018
  • Future consideration
Submitter Name Vincent Paul Wilton
Bomgar Version 18.2.3
  • Attach files