cancel
Showing results for 
Search instead for 
Did you mean: 

Returning traffic from the pool members with a different port

Aspirin240
Nimbostratus
Nimbostratus

Hi,

 

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

0691T000008GrppQAC.jpg

 

 

0691T000008GrpzQAC.jpg

 

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.

4 REPLIES 4

PeteWhite
F5 Employee
F5 Employee

yes, that is why it fails. You may be able to create an ephemeral listener to allow traffic the other way using https://clouddocs.f5.com/api/irules/listen.html

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?

 

  • Performance (Layer 4)
  • Forwarding (Layer 2)
  • Forwarding (IP)
  • Internal

 

You want Performance (Layer 4). You can also do a forwarding VS, only listening on the internal VLAN. You can also listen on a set of ports using port lists, in v14+ iirc