Troubleshooting “Error in Serving the Request” in a Double DMZ UAG Deployment for Horizon
Introduction
Designing a double DMZ architecture for Omnissa Unified Access Gateway (UAG) is a well-established best practice in highly secure environments. By introducing an additional reverse proxy layer, organizations can further isolate internal Horizon infrastructure while still delivering seamless remote access.
However, this added complexity introduces subtle configuration challenges. One of the most common and frustrating errors administrators encounter is:
Error in serving the request.
This article provides a deep technical explanation of the issue, along with practical remediation steps based on real-world experience.
Architecture Overview
In a typical double DMZ deployment:
External Client
│
▼
UAG #1 (External DMZ – Reverse Proxy)
│
▼
UAG #2 (Internal DMZ – Horizon Edge)
│
▼
Horizon Connection Server
UAG #1: Acts purely as a reverse proxy
UAG #2: Provides Horizon Edge services (Blast, Tunnel, PCoIP, HTML Access)
This layered structure enhances security, but introduces strict requirements for header validation, origin checks, and routing consistency.
Symptom Description
Users may encounter: Error in serving the request.
Typically observed when accessing the Horizon portal via browser
In some cases, the error may appear alongside: “Failed to connect to the Connection Server”
Root Cause Analysis
This issue is not a single bug, but rather a validation failure within UAG. It usually results from missing or mismatched HTTP headers and origin validation settings between the two UAG layers.
Key contributing factors:
1. Host Header Validation Failure
UAG performs strict validation of incoming Host headers.
In a double DMZ scenario:
Requests arrive at internal UAG (UAG #2) with the external UAG FQDN
If not explicitly allowed → request is rejected
2. CORS / Origin Validation (HTML Access)
For HTML Access:
Browser enforces CORS (Cross-Origin Resource Sharing)
UAG validates the Origin header
If the external UAG FQDN is not trusted - Connection to Horizon fails
3. Misaligned Horizon Edge Security Settings
Horizon Edge Services enforce:
Allowed Hosts
Allowed Origins
Missing entries cause:
Request drops after authentication
Routing failures masked as generic errors
Resolution
Step 1: Configure Allowed Host Headers
On the internal DMZ UAG (UAG #2):
Navigate to: System Configuration → Allowed Host Headers
For example: <external-uag>.<your-domain>.com
This ensures that requests arriving via the external UAG are accepted.
Step 2: Validate HTML Access Configuration
If users encounter: “Failed to connect to the Connection Server”
You can follow the official Omnissa KB: https://kb.omnissa.com/s/article/2151877
This article provides guidance on Proxy pattern validation, Origin header rewriting and Horizon configuration alignment.
Step 3: Configure Allowed Origins (Critical for HTML Access)
If the issue persists, especially for HTML client access:
On the internal UAG (UAG #2), navigate to Horizon Edge → More Settings
Locate Allowed Origins and Add the external UAG (UAG #1)’s FQDN, as an example:
<external-uag>.<your-domain>.com
Save configuration and test again
Conclusion
The error “Error in serving the request.” is a symptom, not a root cause.
In double DMZ deployments, it almost always indicates:
Missing trust configuration between UAG layers
Header or origin validation failure
By ensuring:
Proper Allowed Host Headers
Correct Allowed Origins
Alignment with HTML Access requirements
You can restore full functionality and maintain a secure, compliant architecture.
Final Thoughts
I hope that this article has provided clarity and helped you successfully troubleshoot this issue in your environment.
If you have any questions, feedback, or would like to discuss similar architectures, please feel free to connect with me on LinkedIn:
https://www.linkedin.com/in/arale-sahar-9340161/
Comments
Post a Comment