Persistent connection issue with SSL and HTTP pools in a VirtualServer Hostgroup

[LouanTessi]

Title

Persistent connection issue with SSL and HTTP pools in a VirtualServer Hostgroup

Setup Details

• CIS Version: 2.18.1
• Build: f5networks/k8s-bigip-ctlr:2.18.1
• BIG-IP Version: BIG-IP 17.1.1.4 Build 0.0.9 Point Release 4
• AS3 Version: 3.53.0-7
• Agent Mode: AS3
• Orchestration: Kubernetes
• Orchestration Version: v1.30.4+rke2r1
• Pool Mode: Cluster

Description

We have multiple Kubernetes services published within a VirtualServer "Hostgroup":

• https://[url1.com]/task-service -> POD IP for task-service (8080: HTTP)
• https://[url1.com]/image-service -> POD IP for image-service (80: HTTP)
• https://[url2.com]/ -> POD IP for Grafana (443: SSL)

We want to enable the reuse of the client <==> F5 connection (Connection: keep-alive header) even when requests are directed to differents pools.

additional information: One Connect enabled on the Virtual Server

Actual Problem

When making a second request to another service, we receive an RST (connection reset), despite using the Connection: keep-alive header.

• Request to https://[url1.com]/task-service: 200 OK
• Request to https://[url1.com]/image-service: RST (connection reset)

This issue only occurs when another rule is configured with an active SSL context pointing to a pool within the VirtualServer Hostgroup:

• https://[url2.com]/ -> F5 -> https://[POD_IP]:443/

ltm.log

warning tmml: POD_IP:8080 -> F5_IP:52097: Connection error: ssl_null_parse: alert invalid record type
warning tmml: SSL Handshake failed for TCP POD_IP:8080 -> F5_IP:52097

The F5 should not initiate an SSL handshake for POD_IP:8080 (HTTP).

Solution Proposed

• Update the configuration to allow persistent connections across multiple services within the same VirtualServer that combines both SSL and HTTP pools.
• Modify the iRules or LTM traffic policies to manage SSL enablement/disablement at the HTTP request level.
• Review and adjust the current configuration to allow switching between different pools while reusing the persistent connection.

Alternatives

A temporary solution is to use the Connection: close header to force a new connection for each request. However, this negatively impacts performance and increases response times.