Cascading Virtual Services
There are situations where incoming HTTPS encrypted traffic needs to be sent to real servers over both HTTPS encrypted and HTTP unencrypted using one VIP. To achieve this, we can use a cascading virtual service, which is a virtual service sending traffic to another virtual service. This article will be an overview of how to archive this.
In this example, we will create a virtual service that has offload and encryption enabled with 2 Sub virtual services. We will use content rules to differentiate the traffic. Requests going to /encrypted will be sent to a real server over 443, and requests going to /unencrypted will be sent to a second virtual service that has a real server over port 80. 10.1.103.162 is a real server accepting encrypted traffic. 10.1.103.161 is a second virtual service that is accepting traffic over 443 and offloading it to the unencrypted real server.
The SSL properties of this virtual service will have both offloading and reencryption enabled. There should also be a valid certificate added to avoid SSL errors.
The initial virtual service has 2 SubVS’s. The first SubVS named “Encrypted” has the following content rule to match on traffic requesting /encrypted.
The second SubVS has the following content rule to match on traffic requesting /unencrypted.
The Unencrypted SubVS is sending traffic over 443 to a second VS, 10.1.103.161. This VS is offloaded by enabling SSL Acceleration and sending traffic to the port 80 real server, 10.1.103.162.
When we request https://10.1.103.160/encrypted we now see we are hitting the encrypted real server.
When we request https://10.1.103.160/unencrypted we see we are hitting the unencrypted real server.
