OneConnect

That depends on how you implement the OneConnect settings.

 

 

The biggest problem is where you share the backend connections amongst multiple clients. The backends only see the IP address (Assuming NAT) of the first client. And thereafter the other client requests will be presented on the same connection and thus the same IP address. Clients will also 'hop' around on random IP's in this case (Not so bad if you use SNAT).

 

 

The biggest problem is where apps expect that all requests on a single connection are from the same client and so only do the auth etc on the first request... The second and subsequent requests then share the sessino of the first and you have a wonderful problem where people see each others information etc...

 

 

OneConnect is very useful where it's got a well written and robust app behind it that's expecting multiple clients multiplexed over a small number of connections... Otherwise it's exposing a bit of a security hole.

 

 

H

Awesome to see a document like that so clearly tailored toward BIG-IP users...I assume that's a product of Microsoft and F5's partnership...cool stuff.

 

 

Anywho, you could always change the mask for OneConnect so it only re-uses connections from the same client. That would certainly reduce your gains though.

Agreed. /32 is the safest way to go, and generally will fix any oneconnect issues that you may run into. Obviously, you'll not get the killer gains from a more wide open mask, but /32 generally gives you much of the benefit without the risks. It's also worth noting that oneconnect can actually help fix certain situations. For example, JSESSIONID persistence often (always?) won't work the way you expect without a oneconnect profile on the VIP. The same goes for plain old cookie insert in certain proxy environments.

 

 

-Matt

Hi we used oneconnection with /32 and hash base cookie persistence (cookie set by the two backend servers) . We do have problem sometime one client seeing other clients information. Just wonding how do F5 determind which response packets need to send back to client ? As more than one client might share the same tcp session between F5 and Webservers . And we also use source NAT on F5. Any Idea ?

Posted By joekyaw on 10/01/2010 04:03 AM

 

Hi we used oneconnection with /32 and hash base cookie persistence (cookie set by the two backend servers) . We do have problem sometime one client seeing other clients information. Just wonding how do F5 determind which response packets need to send back to client ? As more than one client might share the same tcp session between F5 and Webservers . And we also use source NAT on F5. Any Idea ?

 

 

What kind of information are other clients seeing? I use OneConnect with default mask, SNAT, and have the F5 inserting a custom cookie based on the responding server's IP address. If your cookie is inserted by the backend server, are you using an iRule to handle persistence?

Thanks for your reply Chris. Client 1 profile showing up on Client 2 browser, if both client login to the web servers . Unfortunately, we get around 500 user login daily and only reported issue one or two user randomly. Can't recreate the issue.

 

=========================

 

Here is the environment setup

 

=========================

 

clients ----Akamei proxy------(VS)-LTM-(pool)---- 2 Backend servers

 

1. VS configure with OneConnect with /32.

 

2. using VS ip address as source NAT to Backend servers.

 

3. using cookie hash persistence with match across VS.

 

SOL6586: Overview of cookie hash persistence

 

https://support.f5.com/kb/en-us/sol...r=10362909

 

 

Thanks for your help.

 

I'd suspect your backend. We had this a few times with Weblogic several years back as well. I'm not sure if it was the app caching the sessionid and not checking it for every request, or a weblogic bug. But disabling oneconnect certainly fixed it.

 

 

Does it kill your site if you disable oneconnect completely for this VS? Although with only 500 clients/day it probably wouldn't.

 

 

H

Hi Hamish - Thanks for your information. Just wondering after turn off oneconnect on VS. Will it break the persistence ? We are using Cookie Hash method.

 

 

 

Note: F5 recommends that you configure a OneConnect profile in addition to the Cookie profile, to ensure that the BIG-IP system load balances HTTP requests correctly.

 

 

https://support.f5.com/kb/en-us/pro...ml1188358

It's possible that your problem is exacerbated by Akamai here - they use a form of oneconnect as well, assuming you're setup that way. A /32 bit oneconnect mask (255.255.255.255) ensures that each client gets their own socket - it will not be re-used by other clients. This implies that something upstream is multiplexing as well, representing multiple clients as one source.

 

 

The scenario where you really need oneconnect has to do with upstream proxies, which you most definitely have here. I would test with/without it so you can characterize the behaviors in your environment.

 

 

-Matt