Firewall Configuration

Configuration

A network Firewall positioned upstream of Thinfinity® Workspace must maintain secure end-to-end connectivity for prolonged HTTPS and WSS (WebSocket Secure) sessions while implementing strict segmentation across the three architectural tiers: Edge, Orchestration and Control, and Workload Layers.

Objectives:

• Facilitate uninterrupted transmission of TLS 1.2 and TLS 1.3 protocols, as well as WSS traffic, throughout the entire communication pathway.
• Reduce the attack surface by enforcing the principle of least privilege through granular OSI Layer 3 (Network) and Layer 4 (Transport) access controls, complemented by micro-segmentation strategies.
• Ensure compatibility with WebSocket upgrade requests and authentication procedures, preventing disruptions to WebSocket handshake processes or session authentication workflows.

Base Transport Policy

• Permit TCP 443 only on internet-facing listeners; block all plain HTTP.
• No TLS/SSL interception for Thinfinity Workspace data paths.
• Validate current certificates and preferred ciphers (TLS 1.2/1.3). If your firewall supports FQDN (Fully Qualified Domain Names) objects, restrict ingress to your Thinfinity Workspace FQDNs.

WebSocket Handling

Allow the HTTP/1.1 upgrade process involving headers (Connection: upgrade, Upgrade: websocket) and respond with a 101 Switching Protocols status code. Post-upgrade, disable deep payload inspection for encrypted WebSocket frames and instead implement enforcement of rate limiting and concurrent connection constraints. Maintain persistent state entries to manage long-duration connections in accordance with the specifications outlined in the Timeouts section.

Segmented Rule Sets (Reference)

Edge → Orchestration and Control

• LB/WAF → Gateways: Allow TCP 443 (TLS re-encryption) and health checks to the Gateway pool.

Orchestration and Control Layer

• Gateways ↔ Brokers: Allow required control APIs over HTTPS (TCP 443) within the layer.
• Brokers → Identity: Allow LDAPS (636) or LDAP (389), Kerberos (88/464), Global Catalog (3268/3269), DNS (53), and NTP (123) to your AD/DNS/NTP servers.
• Brokers → Database: Permit your chosen engine only (e.g., MySQL 3306 or SQL Server 1433).

Thinfinity → Workloads

• Gateways → VDI/Apps: Allow RDP (3389) for Windows VDI/Server, SSH (22) for Linux, and HTTPS/HTTP to internal web apps as required — scoped per host pool/segment.
• Session Hosts → Profile/File Services: Permit SMB (445) to profile/file shares (e.g., FSLogix) from session hosts only; do not expose SMB broadly.

Egress (as needed)

• CRL/OCSP (80/443) for certificate validation, package repos for patching (scoped), and NTP (123) to trusted time sources.

Inspection & Access Controls

Implement bypass for application-level control and Intrusion Prevention System (IPS) functionalities specifically for WebSocket tunnel endpoints, while maintaining inspection capabilities for standard HTTP(S) control interfaces.

Authenticate and verify the Origin and Referrer headers at the WAF/LB. Ensure that network-layer (L3/L4) allowlists are enforced consistent with the FQDNs of the front-end services.

General Considerations for Traffic Inspection

Allowed HTTP Methods

For Thinfinity Workspace to operate correctly, the firewall and the WAF must allow specific HTTP methods that are essential for authentication flows, API calls, resource loading, and WebSocket upgrades.