This KB outlines the top trending cause associated with an intermittent external screen redirection issue with the Blast Protocol over Unified Access Gateway (UAG)Please see the following KB for other potential causes if the matter is not exclusively seen when routed through a UAG. Troubleshooting Issues with the Horizon Blast Protocol (90139 )Session Misrouting: The Blast Protocol- Traffic not arriving in the expected place. Common Reasons for Session Misrouting:A Misconfigured Blast Secure Gateway (BSG): A UAG is configured with an address that misroutes the traffic. This can be as simple as a typo or if, for instance, Two UAGs are configured with the same BSG URL which statically routes to only one UAG.Local Networking Device Misconfiguration:A device on your network blocks or misroutes traffic. For Example, this can include but is not limited to corrupt firewall rule load balancer persistenceblocked port on an infrequent path.
In order to effectively troubleshoot an intermittent issue, we need a good understanding of the expected traffic flow of the protocol so traffic flow that is outside of the norm can be quickly identified.Our Techzone Resources on Understanding and Troubleshoot Horizon Connections and Network Ports in Horizon offer greater detail than the brief summary below and are also excellent reference material to ensure stakeholders can be dialled in quickly. Expected Protocol-Traffic Flow :Primary Protocol - Authentication: The Horizon Client initiates an authentication stream. This initial connection handles authentication, authorization, and Session Management. It uses the XML-API protocol over HTTPS and is typically load-balanced.Within your UAG, The configuration of the XML-API protocol is represented by the TunnelExternalURL value. Reference Documentation: Configure Horizon SettingsThe URL set here for TunnelExternalURL will be the path engaged by the Horizon Client to initiate this authentication stream. Note: When load balancing Horizon traffic to multiple UAG appliances, this initial XML-API connection should be load balanced. For more granular detail, please reference Documentation: Unified Access Gateway Load Balancing Topologies Secondary Protocol - Screen Redirection: Tunneling is set on the UAG so after Primary authentication is complete, we directly negotiate with the Virtual Desktop.The UAG ensures the Secondary Protocol is authorized based on the established session. Incorrect Traffic Flow In the above example, UAG1 authenticated the primary protocol.Some outside factor routed the Secondary Protocol to UAG2 UAG2 has no authentication record and drops the unauthenticated connection attempt. In Summary: The secondary Horizon protocols must be routed to the same UAG appliance to which the primary Horizon XML-API protocol was routed. This allows the UAG to authorize the secondary protocols based on the authenticated user session.If the secondary protocol session is misrouted to a different UAG appliance from the primary protocol one, the session will not be authorized. The connection would be dropped in the DMZ, and the protocol connection will fail. Log Review Validation: You can confirm this behaviour in the Unified Access Gateway Logs: The example below is from the blast log file (bsg.log) located in /opt/vmware/gateway/logs within each individual UAG.This logfile can be accessed via the shell interface on each UAG or by downloading the archive after simulation of a black screen Supporting Documentation:Collecting Logs from the Unified Access Gateway ApplianceManage VMware Unified Access Gateway using SSH (2145537) Loglines following a sample blast session: On UAG1 above, The route B99B5A82 is added to an IP on the blast port 22443, preparing BSG for an incoming connection. This happens as the primary protocol is authenticated on UAG1. UAG1/bsg.log:[2022-12-03 15:01:33.557] [INFO] 1198 [absg-master] - Added route B99B5A82-*** to target 192.168.5.17|22443 This blast client connection was not received within our default one-minute timeout. UAG1/bsg.log:[2022-12-03 15:02:33.557] [INFO] 1198 [absg-master] Removing idled route B99B5A82-*** to target 192.168.5.17|22443 , idled for 60.00 seconds, registered for 60.01 seconds. When we open the equivalent BSG logs on UAG2, we can see this identical route (B99B5A82 ) failing to resolve. UAG2/bsg.log.1:[2021-12-03 16:30:47.496] [ERROR] 1685 [absg-worker] - Failed to resolve proxying route: B99B5A82- As blast is a secondary protocol, its traffic needs to remain on UAG1 and as there is no authorization on UAG2, the traffic is dropped as per the design. The log lines above are indicative of a misconfigured blast URL or an outside force (session affinity, routing, DNS) to cause this: The Blast connection and other secondary protocol connections must always be routed to the same UAG appliance otherwise it will fail. The blastExternalUrl must use a hostname that guarantees the Blast Connection will get to the same UAG appliance. Common Questions: Question: "I have 2 UAGs but don't see the idled route on the corresponding UAG?" " I only have one UAG Appliance and I see these loglines? "Answer: If you see the idled 60-second logline but do not see the corresponding session entry on another paired UAG appliance or just have the one UAG appliance - This dropped incoming client connection can also be a blocked port.Blast Extreme is a TCP-based protocol utilizing WebSockets, but it can also be configured to use UDP. TCP is the most versatile as it’s not likely to be blocked - WebSockets do often require enabling on network devices.Question: " I have HA configured between my two UAGs - Is this applicable to my configuration?"Answer:Yes, The same rules apply. Connections for the secondary protocol must be made through the specific individual UAG that handled the client's login and desktop/app selection interactions.Question: How do I load balance now?Answer:You still can. The initial XML-API connection (authentication, authorization, and session management) can remain load-balanced. The selection of the Secondary protocol is initiated after this. The first connection will always be the primary XML-API protocol over HTTPS. Following successful authentication, one or more secondary protocols are then initiated. Where the load balancer does not have this capability, or where source IP affinity cannot be used, another option is to dedicate additional IP addresses for each Unified Access Gateway appliance so that the secondary protocol session can bypass the load balancer. This is often referred to as the N+1 VIP method where a load-balanced VIP is used for the primary protocol and the secondary protocol is routed directly to one of the N VIPs dedicated to each Unified Access Gateway appliance. Please review our documentation for additional details on Loadbalancer Configuration and Best Practices:Load Balancing Unified Access Gateway for Horizon Loadbalancer Investigations: Load balancers can be removed temporarily to confirm the source of the errors.You can raise a recommended Load Balancer persistence setting please see Monitoring health of Horizon Connection Server using Load Balancer, timeout, Load Balancer persistence settings in Horizon 7.x and 8 (56636) Host Redirection: For those scenarios where it is not realistic to disable a load balancer and wish to minimise disruptions during the course of investigations, A connection server feature from Horizon 2209 & later can help avoid issues with affinity control. From UAG 2303, Unified Access Gateway Support for HTTP Host Redirect complements this feature for issues with devices and also contains its own Host Redirection Feature Reference: Unified Access Gateway Support for HTTP Host RedirectUAG Configure Horizon Settings - Honor Connection Server RedirectHorizon Installation and Upgrade - Enable Host Redirection
https://techzone.vmware.com/resource/blast-extreme-display-protocol-vmware-horizon-7#blast-extreme-network-connections