Skip to Content

Understand Absolute vs. Relative URLs in Server Redirects 302

By: Author Alex Lim

Posted on

Categories Troubleshooting

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.

http 302 found redirect

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

These HTTP headers are negotiated between the browser and the final server and FortiGate does not strip or change it. A fix should be applied to the server, 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

  1. The PC accesses the server at http:// website.lab:4445 /redirect-full-externalsite/
  2. The server responds with an HTTP 302 redirect to an external site `https:// www. sapo .pt`.
  3. The PC follows the redirect and accesses the external site successfully.

Explanation: This scenario works because the external site is publicly accessible.

redirect to external site using absolute URL

2nd Scenario: Attempting to redirect to the level-2 folder using absolute URL.

  1. The PC accesses the server at http:// website.lab:4445 /redirect-full-to-level-2/
  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/`.
  3. 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.

Attempting to redirect to the level-2 folder using absolute URL

3rd scenario: Redirect to the level-2 folder using relative URL (to the request URL).

  1. The PC accesses the server at http:// website.lab:4445 /redirect-relative-to-level-2/
  2. The server responds with an HTTP 302 redirect to a relative path within the same server `/level-2/`.
  3. 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’.

Redirect to the level-2 folder using relative URL (to the request URL)

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 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