Description
This article explains different redirection scenarios in a server environment, focusing on the use of absolute and relative URLs.
When protecting or migrating a server behind a FortiGate using a VIP, virtual server (VS), or ZTNA server a wrong redirect from the server side can lead the user to an IP or URL that is not accessible externally.
Scope
FortiGate v6.4, v7.0, v7.2, v7.4, VIP, Virtual Server, ZTNA.
This information is useful for network administrators, web developers, and IT support staff involved in configuring and troubleshooting server redirects.
Solution
When using HTTP Virtual Servers (VS) on FortiGate, HTTP headers are typically negotiated between the browser and the final server. FortiGate only alters these headers if specific features are enabled, such as NAT or the translate-host feature, which is enabled by default under the VS configuration.
- Starting from FortiGate v7.2.4 and v7.4.0, the translate-host feature can impact how web servers create HTTP 302 redirects. FortiGate forwards the request to the server with the 'real server' IP or FQDN on the host header instead of the original IP or FQDN.
Certain web servers may append the host from the request to the path ("/") in the response sent to the client. If this behavior causes issues translate-host feature should be disabled. Refer to Technical Tip: Function and Behavior of the Virtual Server 'translate-host' Setting - If disabling the translate-host feature does not resolve the issue, a fix on the web server is necessary, explanation follows.
Redirection Scenarios:
Both 'redirect-full-to-level-2' and 'redirect-relative-to-level-2' are pointing to the same server, but the first is utilizing an absolute URL, and the second is using a relative URL, respectively.
1st Scenario: redirect to external site using absolute URL
- The PC accesses the server at http:// website.lab:4445 /redirect-full-externalsite/
- The server responds with an HTTP 302 redirect to an external site `https:// www. sapo .pt`.
- The PC follows the redirect and accesses the external site successfully.
Explanation: This scenario works because the external site is publicly accessible.
redirect302to-sapo2nd Scenario: Attempting to redirect to the level-2 folder using absolute URL.
- The PC accesses the server at http:// website.lab:4445 /redirect-full-to-level-2/
- The server responds with an HTTP 302 redirect to a full URL within the internal network `http:// 192.168.5.40:8085 /level-2/`.
- The PC attempts to follow the redirect but fails because `192.168.5.40` is a private IP address, which is not accessible from outside the internal network.
Explanation: This scenario does not work because the external PC does not have access to the private IP address of the server and it is exposing private IP.
3rd scenario: Redirect to the level-2 folder using relative URL (to the request URL).
- The PC accesses the server at http:// website.lab:4445 /redirect-relative-to-level-2/
- The server responds with an HTTP 302 redirect to a relative path within the same server `/level-2/`.
- The PC follows the redirect and accesses the relative path on the same server successfully.
Explanation: This scenario works because the redirection is within the same server and does not rely on accessing a private IP address as it uses the 'Referer'.
Recommended approach:
Using relative URLs ensures that the redirection stays within the same server context, which avoids issues with private IP addresses that are not accessible from outside the internal network. This method ensures compatibility and accessibility for external PCs without requiring changes to DNS settings or public IP configurations.
By using relative URLs, it maintains a robust and consistent redirect mechanism that works seamlessly regardless of whether the client is accessing the server from within the internal network or from an external location.
Change the server settings to use a relative path or set up FQDN on both server and public DNS if absolute is required.
For enhancement control and rewriting of layer 7 requests and responses, refer to products such as FortiWeb or FortiADC.
For ZTNA: If for whatever reason a change in the server or service is not possible the alternative solution is to use a TCP forwarding access proxy
Related documents:
Mozilla - HTTP Headers Location
Location on rfc7231 HTTP Semantics and Content
Technical Tip: Function and Behavior of the Virtual Server 'translate-host' Setting
