We recently encountered a recurring issue impacting the accessibility of Jumpoints, which we have traced back to behaviors described in KB0021363. The root of the problem appears to be interference between the old and new network management features, particularly when IP assignments are modified either through binding on virtual machines' NICs or via IP changes on bare metal systems.

Observations

When these changes occur, the resulting network configuration across the multiple management interfaces becomes inconsistent. This inconsistency causes the Jumpoint to:

• Attempt to resolve to its own address,

• Become entirely unresolvable, or

• Exhibit packet fragmentation or corruption during analysis.

Network inspection tools and bomgar logs show erratic behavior. Logs typically reveal incomplete packets or generalized packet errors, but offer no definitive indicators as to the root cause. The symptoms include:

• Dropped connections,

• Fluctuating tunnel availability,

• Inconsistent routing behavior across subnet access attempts.

• Handshake issues and/or outgoing traffic but none incoming 

Mitigation and Temporary Solution

To address this, we have transitioned our network tunnels to Red Hat servers. Since making this change, the system has remained stable and fully operational for over 10 days. Notably, we observed that when accessing different subnets simultaneously through the same Jumpoint on Red Hat systems, no issues arise. This suggests that Red Hat's network stack and management layer provide better compatibility or isolation between management interfaces under the conditions described.

Next Steps

We are continuing to test alternative Linux distributions and Windows configurations to identify reliable and compatible setups while awaiting a formal patch or update, any other info from the community is greatly appreciated.

Recommendation

For teams encountering similar Jumpoint inaccessibility or tunnel instability, consider testing with Red Hat or other Linux distro.