307 Redirect Loop When Multiple Authentication Realms Share the Same Virtual Host on an HTTP/2 Connection
search cancel

307 Redirect Loop When Multiple Authentication Realms Share the Same Virtual Host on an HTTP/2 Connection

book

Article ID: 445430

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

Users experience a continuous 307 redirect loop when accessing URLs that require authentication through a second realm, after already having authenticated through a first realm. The loop occurs at the virtual host URL configured for form-based or origin-redirect authentication. 

The policy trace shows:

authentication status='invalid_surrogate'

Last Error: The surrogate is invalid for the specified realm.

verdict: REDIRECT(authentication_redirect_to_virtual_host)

client.response.code: 307

The browser is redirected repeatedly to the virtual host URL but the authentication form is never presented, or credentials are submitted but the loop continues. The issue only occurs with HTTPS traffic (HTTP/2 connections); HTTP traffic or environments where HTTP/2 is disabled are not affected. 

Conditions Required to Trigger the Issue 

All of the following conditions must be true to trigger the issue: 

  • Two or more authentication realms are configured (for example, REALM_A for general traffic and REALM_B for a specific URL category such as shopping or social networking).
  • Both realms are configured with the same virtual-url (the same IP address and port).
  • The client's connection to the proxy uses HTTP/2 (H2). This requires HTTPS traffic with SSL interception enabled, and a client browser that negotiates H2 via ALPN.
  • The client has already authenticated in REALM_A before requesting a URL that requires REALM_B.

Environment

SGOS 7.3.28.2 and later, and all 7.4.x releases

Cause

HTTP/2 multiplexes multiple request streams over a single TCP connection. Because many streams can be active simultaneously on one connection, the authentication subsystem faces inherent difficulty in accurately tracking which user is authenticated in which realm for each individual stream at any given moment. Unlike HTTP/1.1 — where each connection carries exactly one request at a time — H2 allows concurrent in-flight requests that may belong to different authentication contexts, making it challenging to maintain a consistent, per-stream view of realm membership across the auth subsystem.

This difficulty is compounded when both realms share the same virtual host address and port. An HTTP/2 client reuses its existing H2 connection for the VH redirect (RFC 7540 §9.1.1 connection coalescing), so the VH visit arrives over the same connection (and the same pool of concurrent streams) as the original request. The auth subsystem is therefore unable to cleanly isolate the incoming VH authentication attempt from the already-active streams, and the cross-realm transition is not handled correctly. The result is that the user is redirected back to the original URL without ever being presented with an authentication challenge, and the cycle repeats.

On HTTP/1.1, each VH visit opens a new TCP connection. There is only ever one request in flight on that connection, so realm context is unambiguous and the transition is handled correctly.

Resolution

Configure the virtual host on a dedicated IP address or port that is separate from the address and port through which normal proxy traffic flows. This forces the client browser to open a new connection to the VH, preventing H2 connection coalescing. Configure that dedicated listener to refuse H2 (accept connections as HTTP/1.1 only), ensuring each VH authentication request gets its own isolated session.

The workaround involves three steps: network configuration, proxy service configuration, and policy.

Configuration Steps

Use the following procedures to configure a dedicated virtual host and prevent the redirect loop. 

Step 1: Assign a Dedicated Address to the Virtual Host 

The VH address must differ from the address on which normal proxy traffic arrives, in either IP address or port number. Two options are available:

Option A: Different IP address (recommended if additional IPs are available) 

Add a secondary IP address to the appliance network interface. The exact command depends on the interface name shown by show interface:

interface <interface-name>

  ip-address <new-VH-IP> <subnet-mask>

exit

 

Example:

interface eth0

  ip-address 192.168.77.81 255.255.255.0

exit

 

Option B: Different port on the same IP address 

If a second IP is not available, use a different port (for example, 9443). Note that this port must be reachable from clients. Verify that any firewall between the client and the appliance permits traffic on the new port.

Step 2: Create an HTTPS Reverse Proxy Service for the Virtual Host Address 

The Edge SWG appliance does not automatically create an HTTPS Reverse Proxy service. One must be created for the dedicated VH address.

From the Admin Console, perform the following steps: 

  1. Navigate to Configuration > Services > Proxy Services
  2. Click New Service
  3. Enter a name (for example, VH-Auth-Service)
  4. From the Proxy settings drop-down, select HTTPS Reverse Proxy
  5. Select a Keyring (the default keyring is suitable for initial configuration)
  6. In the Listeners area, click New and configure:
    • Source address: All
    • Destination address: the dedicated VH IP address added in Step 1 (Option A), or All with the dedicated port (Option B)
    • Port: 443 (Option A) or the dedicated port number (Option B)
    • Action: Intercept
  7. Click OK, then Apply

Step 3: Update the Virtual URL on Each Realm 

Change the virtual-url on every realm that was sharing the old VH address to use the new dedicated address. All realms may point to the same dedicated VH address; they do not require separate addresses from each other.

From the Management Console, navigate to Configuration > Authentication, select each realm, and update the Virtual URL field:

Option A (different IP, same port): 

virtual-url = https://192.168.77.81

 

Option B (same IP, different port):

virtual-url = https://192.168.77.80:9443

 

To verify the change took effect:

show authentication realm REALM_A

show authentication realm REALM_B

Both should show the updated virtual-url.

Step 4: Add Policy to Disable HTTP/2 on the Virtual Host Listener 

Add the following to the <Proxy> policy layer. This disables HTTP/2 acceptance on connections arriving at the dedicated VH address, ensuring all VH authentication connections use HTTP/1.1.

 

Option A (different IP, port 443):

<Proxy>

  proxy.address=192.168.77.81 http2.client.accept(no)

 

Option B (same IP, different port):

<Proxy>

  proxy.address=192.168.77.80 proxy.port=9443 http2.client.accept(no)

 

Notes on this policy:

  • proxy.address= matches the destination IP address of the incoming connection. For Option A, only connections arriving at the dedicated VH IP match; regular proxy traffic on the original IP is unaffected.
  • proxy.port= matches the port the client is connecting to. For Option B, only connections on the dedicated port match.
  • http2.client.accept(no) causes the proxy to negotiate HTTP/1.1 (not H2) on the matched connections.
  • This policy must be placed in the <Proxy> layer. It is evaluated at connection time, before ALPN negotiation completes.
  • Do not guard this action with client.connection.ssl_server_name=. This combination is not supported for HTTPS reverse proxy transactions.

Verification

After applying all changes, perform the following steps to verify the configuration in the Admin Console: 

  1. Confirm the HTTPS Reverse Proxy service listener is active by navigating to Configuration > Services > Proxy Services and verifying the new service appears with status Enabled.
  2. Confirm the realm virtual-url values are updated by entering the following commands:
    show authentication realm REALM_A

    show authentication realm REALM_B
     
  3. Test connectivity to the VH directly from a client browser by navigating to the new VH URL (for example, https://192.168.77.81 or https://192.168.77.80:9443). The appliance should respond with an authentication challenge or form. If the browser cannot connect, verify firewall rules and that the new service listener is configured on the correct address.
  4. Test the end-to-end authentication flow:
    • Clear the browser session (or use a fresh private window to ensure no cached H2 connections).
    • Access a URL requiring REALM_A — authentication should succeed.
    • Access a URL requiring REALM_B — the browser should follow the 307 redirect to the new VH address, open a fresh HTTP/1.1 connection, present an authentication challenge, and on successful authentication redirect back to the original URL without looping.
  5. Check that the client IP is registered in both realms' surrogate tables after authentication. Navigate to https://<appliance-management-IP>/Auth/IP-Logins to view active IP surrogate sessions by realm.

Alternative Workaround: Disable HTTP/2 Globally

If adding a dedicated VH address is not feasible, HTTP/2 can be disabled globally for all client-side connections. This eliminates the problem entirely at the cost of disabling H2 for all proxy traffic.

<Proxy>

  http2.client.accept(no)

Note: This is a blunt instrument. All HTTPS connections through the proxy will negotiate HTTP/1.1 instead of HTTP/2, which may reduce performance for sites and clients that benefit from H2 multiplexing. Remove this policy line once a permanent code fix is available.

 

Additional Notes

  • Transparent proxy deployments: The workaround applies equally to transparent and explicit proxy deployments. In transparent mode, the original HTTPS traffic is intercepted toward internet server IPs, which are different from the appliance's own IP. The H2 coalescing problem occurs specifically at the VH level (both VH visits going to the same IP:port), not between normal internet traffic and VH traffic. The dedicated VH address breaks this coalescing at the VH level.
  • WCCP/PBR in transparent deployments: Confirm that the new VH IP address is either the appliance's own interface address (reached directly, not via WCCP redirection) or that WCCP/PBR rules are updated appropriately to handle traffic to the new address. If WCCP is configured to intercept all port-443 traffic including traffic to the appliance's own IPs, the new port (Option B) may need an explicit WCCP exclusion rule.
  • SSL certificate: The HTTPS Reverse Proxy service requires a keyring with a certificate. For internal deployments where the appliance's CA certificate is already trusted by clients (for SSL interception), the default keyring is sufficient. If clients do not already trust the appliance CA, either use a CA-signed certificate or distribute the appliance CA to clients.
  • Multiple realms, one virtual host: All realms that previously shared the same VH address can share the new dedicated VH address. They do not each require a separate dedicated address. The H1-only constraint on the dedicated VH handles cross-realm transitions correctly because HTTP/1.1 performs proper session resets on realm transitions.

 

Powered by Wolken Software