Traffic Policy to Split Content Between IIS Server and Cloud Provider - unexpected behavior
We are in the process of moving a website from an IIS web server farm out to a different cloud hosting provider. The root of the rewritten site will be on the cloud servers. Since not all of the old legacy applications have been rewritten, we will still be serve up some of the legacy web applications from the old IIS servers. To achieve this, we are using the following:
VIP with a default pool "Cloud_Provider" . That pool contains the IP address of that provider.
VIP has a Traffic Policy associated with it that has a rule of:
Match all of the following conditions: HTTP URI path starts with any of: /oldapp1 at request time
Do the following when the traffic is matched: Forward traffic to pool "IIS_pool"
The following scenerios work as expected and correctly serve up the web content:
https://HostName.com/ (this successfully loads the site from the cloud provider)
https://HostName.com/oldapp1 (this successfully loads the legacy app from the IIS Servers)
However... If we first go to https://HostName.com/oldapp1 and successfully load that, then we remove "/oldapp1" from the address bar and hit Enter, it attempts to load the root of the site in IIS. Since there is no more root site (it is now living on the cloud provider as a rewritten site), it sees no content and spits out a 403 Forbidden message.
What we are trying to solve is, why when running through that second scenerio, is the traffic not going through the Traffic Policy again and seeing "this request is not for oldapp1" so I will not forward the traffic... I will just use the default pool.
Troublshooting steps taken so far:
Tried changing the Persistence Profile on the VIP to: source_address, ssl, cookie, none.
Put an index.html file at the root of the IIS web server and had it redirect to https://HostName.com. That resulted in an endless loop because it never left the IIS server to go back through the VIP.
This is running on 15.1.5.1, with ASM.
Better to add a default rule in your policy pointing to the default pool instead of relying only on the VS default pool. With this you are sure the system apply the intended action for every request without taking into account some VS options (eg. oneconnect)
The behavior you described may indicate that F5 is not resetting the default pool selection as described in details here : https://support.f5.com/csp/article/K15097