F5 UAG SharePoint 2010 (NO DIRECT ACCESS)

Any help here guys ? Can someone tell me if the Direct Access guide is applicable to UAG with no Direct Access !! it looks a bit overkill with all the irules and and ipv6 configuration !!

 

I managed to make the setup work this way:

 

F5 VIP (UAG VIP= Persistence Profile = Source_Addr) => 2 UAG servers (Array with Non integrated NLB) => F5 VIP (SharePoint = Persistence Profile = Cookie) => 2 SharePoint servers

 

Joe.... You're config seems correct. What access protocols (Teredo, IP-HTTPS, 6to4, SSTP, etc.....) are you looking to use? That will have an effect on your need for persistence on the outside UAG VIP.

 

 

The Direct Access / UAG guides were designed to be more comprehensive, so they include detail on IPv6 and such, but that wouldn't necessarily be needed in all deployments. The iRule is for allowing for 'Manage Out' support, which from the sound of it, isn't needed in your deployment.

No teredo, no ipv6. Plain HTTPs VIPs (with http to https redirect when users type just http or the hostname in their browsers).

 

Any idea how the source_addr persistence profile works. I'm not a BigIP expert; I use the Virtual Appliance (10.1) to test my setups before asking the F5 guys here to configure the company BigIp devices (which are also ver 10.1).

we are using https vips with ssl client/server profiles for the 2 vips This adds load on the f5 boxes but this is a requirement.

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).

Posted By lazar on 03/21/2013 01:43 PM

 

Are you utilizing SNAT at all in your configuration to maintain the authentication state between UAG and Share Point? Just curious to see how that is working?

 

 

 

We use SNAT only because we test UAG portal connection from a server which is in the internal route of the UAG servers (Internal LAN).

 

We plan to remove the SNAT since users will be coming only from the external network so only route UAG will take back to the requesting client is the BIGIP internal (floating IP).

 

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.

 

Ryan, my current design dilemma resides around the current design is for SSL pass through. So we are restricted at the time being to sorce-based persistence. I am working on getting ssl bridging approved as a design modification, because as you stated, the cookie persistence would be better.

 

 

You bring up a design point a need to look into though regarding persistence mirroring. We are currently doing connection mirroring across our HA pair, but not considering persistence mirroring at all - need to look into this.

 

 

 

I tested with cookie persistence and it also works. What I still need to know is how is loadbalancing working in this scenarion:

 

clients (several IPs) => proxy (1 IP seen by the F5 Box) => VIP => Web servers. The F5 box is seeing only one client ip requesting access to the web servers !!!! How is the F5 box able to send traffic to the this server or the other without getting mixed up?