We have an IIS application that is communicating with the client using HTTPS/443, we have a basic VS setup to load balancing between 3 pool members. .Recently we have introduced a new feature in the application where the pool member will communicate back to the client on port 90xx (for a peripheral that's attached to the client machine) once the connection on 443 has established, now everything is working fine on 443 but once the IIS application trying to communicate the peripheral on 9014 then nothing will happen.
Now after doing a TCPDump we have this
So the question is, is it because the VS doesn't know anything about this is traffic that's why it doesn't SYN, ACK to complete the 3 way handshakes?
Sorry if the question is not clear, I am very new to the F5.
Thanks. Any help will be appreciated.
You can use FastL4 profile to sort it out. There's an option called loose-initialization and another one called loose-close. When loose-initialization is enabled, traffic received populates connection table even if connection is not established. This allows asymmetric traffic to go through F5. If failover occurs active connections will still be maintained because Loose Initiation just doesn't care if 3-way handshake has already been established or not. When this setting is enabled it is desirable to enable loose-close as well as BIG-IP will delete and close loosely-initiated connection upon receiving the first FIN from either client or server. Have a look at this article: https://support.f5.com/csp/article/K13558
It's not updated but still good. I'm not entirely sure how's your set up but as Pete said above, you can either an ephemeral listener or create multiple listeners (virtual servers) for returning/outgoing traffic and it should work just fine.
Thanks Peter and Rodrigo for the suggestions,
I was trying to test with FastL4 profile but it wouldn't let me because I am using "Standard Type". Out of the 4 types that are supported by FastL4 which one should I pick?