A portal Access link is designed to proxy access to another webserver.
This might be internal to the network and thus not directly available to the client.
It might be an external server such as mail or an externally hosted intranet.
An external server should be using https. However the hosting company may be using SNI to operate name based hosting.
This is where the client offers the name of the target server as part of the TLS CLIENT_HELLO.
The server will then present the correct certificate to the client.
But if the client does not, the server may well terminate the connection.
It may offer a handshake failure, or just RST the tcp connection.
When a portal access link is clicked for a https server, the connection is established by the VIP using the Server-SSL profile attached to it..
This does not have a "Server Name" (SNI) field set so a SNI requiring destination will drop the connection.
The simple solution of adding a Server Name field does not work because:
As of version 13.1, there is no official F5 "one tick" solution for this.
We need to pick the hostname that the re-writer is going to use and patch the Server SSL connection to have that as the SNI name.
We need to add 2 irules to our VIP.
One to get the hostname and then to patch the outgoing TLS connection with that name.
They must be in that order.
If you are wondering about
set ext_exists [SSL::extensions exists -type 0]
This will work on all V11.2 or later systems.
In V12 and later we can test for SSL::SNI name directly. We wont use that.
Credits to whomever wrote the SSL::extensions insert command!
This is part of
ID653495 Inappropriate SNI hostname attached to serverside connections
K05411532: The BIG-IP system fails to rewrite the SNI host name to the server name specified in the Server SSL profile
So hopefully this is not needed with versions 13.1 and later.