SSL and Uri Rewrites

I have the following issue and wanted to be sure I have the correct understanding

I have configured SSL bridging on my F5, so at a high level this is:

SSL Session between Client and F5

F5 decrypts, inspects with WAF

SSL Session (separate) between F5 and backend server.

I have a requirement to rewrite a uri from service.abc.com to host serverxyz.com

Internally my testing works

Externally my testing fails

Does this mean that the external client has to be able to reach the host serverxyz.com (dns/IP)

I think the rewrite forces the client to attempt a direct connection?

Is it possible to combine SSL bridging and uri rewrites?

Hello @sjy2025

Yes, it is totally possible and fully supported.

Your issue is most likely application-related, not SSL bridging itself. You need to check whether the application uses relative paths or if it has FQDN hardcoded in its responses.

If the application returns redirects, links, or cookies that reference serverxyz.com, then the client will try to connect directly to that hostname, which would explain why it works internally but fails externally.

In that case, you may also need to rewrite the responses, not just the incoming request.

Thank you for clarifying that this is the behaviour.

At the moment I have a rewrite profile attached to the Virtual Server

It is configured as client  service.abc.com to server serverxyz.com type request

Are you suggesting I might ned to reconfigure this to be both

Or do I need an additional rule?

Rewrite profile will do the basics for both directions (HTTP headers, URIs, Cookies)
But your problem might exists in payload (eg JS)
You best opion is, if possible, to configure app itself to not hardcode fqdn anywhere.
If this is not possible, then you have to do some reverse engineering and try to modify fqdn whenever needed with irule.

A colleague of mine came up with the following, I’ve changed the hostnames/ports etc

It partially works but we are not sure if its fixing anything

Also if I remove the rewrite profile it fails

when HTTP_REQUEST {

# 1. SELECT THE POOL (Traffic Steering)

# Replace ‘/specific-path’ with your actual URI path (e.g., /portal)

if { [HTTP::uri] starts_with “/examples” } {

pool poolA

} else {

# Default all other traffic

pool poolB

}

# 2. FIX THE redirect_uri PARAMETER (The new fix)

# This searches the URI for the internal name/port and replaces it with the public one

if { [HTTP::uri] contains “redirect_uri” } {

set internal_1 “hosta:20000”

set internal_2 “hostb:2223”

set public “external.wideip.com”

# Rewrite the URI to swap internal info for public info

set new_uri [string map [list $internal_1 $public $internal_2 $public “http://” “https://”] [HTTP::uri]]

HTTP::uri $new_uri

}

# 3. Preparation for Stream Profile

HTTP::header remove “Accept-Encoding”

STREAM::disable

}

when HTTP_RESPONSE {

# 3. FIX THE URL BAR (Redirects)

if { [HTTP::is_redirect] } {

set loc [HTTP::header Location]

# Mapping all internal variations to your public HTTPS URL

set map_list {

“:20000” “”

“:2223” “”

“http://” “https://”

“hosta” “external.wideip.com”

“hostb” “external.wideip.com”

}

HTTP::header replace Location [string map $map_list $loc]

}

# 4. FIX THE PAGE CONTENT (Requires Stream Profile)

# Replaces internal names/ports found inside the HTML code

STREAM::expression “@hosta:20000@external.wideip.com@@hostb:2223@external.wideip.com”

STREAM::enable

The above worked, with a few missing firewalls rules.