F5 UAG SharePoint 2010 (NO DIRECT ACCESS)

Posted By Ryan Korock on 03/21/2013 06:06 PM

 

OK.... Now I get it. You are using UAG purely as a reverse proxy for SharePoint. It also sounds like you are decrypting and rencrypting at each BIG-IP hop.

 

 

With SharePoint 2010, persisting a user to a specific front end does provide *some* benefit, and may be a requirement if you are running a custom app on SP.

 

 

I recommend using a cookie based persistence method over source IP if you can. If you use Source IP based persistence you'll start to see clumping if a large number of users are coming in from the same source IP (say a branch office...). Cookie persistence is based off a hash (no lookup table needs to be maintained on the BIG-IP!) which takes very little resources for the BIG-IP to calculate, and it survives a BIG-IP failover without having to mirror over any persistence tables.

 

 

Since you are decrypting/re-encrypting at both BIG-IPs, you could use cookie persistence at both (be sure to use different persistence profiles that name the cookie something different for each tier of BIG-IP).

 

 

Not as a reverse proxy but simply as a load balancer. users request http://corpportal.com, they are redirected to the VIP on the BigIP which aks one of the UAG servers which in turn is redirected to a BigIP VIP which redirects to 2 SharePoint servers.

 

As for SSL decrypting/re-encrypting is done in three places (External VIP => UAG => SharePoint). Full SSL encryption from client to server.

 

I did think source_addr persistence profile kind of makes no sense in a load balancing scenario but I still do not see how it works really. I will have to do some reading on the f5 kb website :-)

 

And important thing here like you mentionned, the external VIP will allways see only 2 requesting IP addresses and those are the IP of our proxies positionned before the external UAG VIP

 

I will try the cookie session profile between the external VIP and the UAG and see how it works.