Dec 13 2011

Lync Mobility on WiFi with a KEMP LB

Posted by Brian Ricks at 7:51 AM
4 comments
- Categories: 2010 | mobile | KEMP HLB | Lync | Lync Server

Like many I was excited to see the mobility client finally released for Lync 2010 but needed to figure out what communication was going where - can't fix what you do not understand.

The issue

When using mobility, internally or externally, all communication flows from the mobile device to the External Web Services of your pool. The concept is that there is a single point of communication regardless of your network allowing communication to seamlessly move network to network. In order to achieve this, the external services URLs must be reachable internally when a client access port 443.

The Load Balancer

That requirement was not as daunting as one might think when using a Hardware Load Balancer, in this case it was my KEMP. The key on the KEMP was to have two VIPs created, one for internal communication and one for external communication. The configuration looked something like this:

Internal Web Services VIP
10.10.10.10:443 --> 10.10.10.50:443
10.10.10.10:80 --> 10.10.10.50:80

External Web Services VIP
10.10.10.20:443 --> 10.10.10.50:4443
10.10.10.20:80 --> 10.10.10.50:8080

With this configuration, the port address translation happens on the HLB so the Reverse Proxy or Firewall can send the external traffic unchanged. Internally, the communication is always bound for HTTP/HTTPS and then changed depending on the destination IP.

Data Flow

Looking at communication from a phone via cellular and WiFi then looks like so:

Cellular
Phone IP (12.5.5.23) --> Ext AutoDiscover (68.5.12.54:443) --> Ext Web Services URL (68.5.12.54:443) --> HLB (10.10.10.20:443) --> Lync Pool External Web Services (10.10.10.50:4443)

WiFi
Phone IP (10.10.10.100) --> Internal AutoDiscover (10.10.10.10:443) --> Int Web Services (10.10.10.10:443) --> Ext Web Services URL/HLB (10.10.10.20:443) --> Lync Pool External Web Services (10.10.10.50:4443)

As you can see both methods end up going to the external web services which is managed by the KEMP HLB. The only difference is when on the internal WiFi it is able to resolve the internal pool which passes the Mobile URL information back which is the external web services URL. Because the external web services URL resolves internally to the VIP created for the external web services, it is redirected to port 4443.

That sets the data flow as we want, now the only thing left is the configuration of the KEMP HLB which requires the setup using cookies for persistence (again referencing Dave Howe's article here).

Configuring the HLB

The KEMP configuration for Lync is fairly easy with the setting below. You will need your external certificate so that is can be loaded into the HLB (public and private key) as it will need to decrypt and re-encrypt the communication. An example configuration would be:

Basic Properties
Service Type: HTTP/HTTPS
L7 Transparency: Disabled
Real Server Check Parameters: Optional but recommended
Service Nickname: Lync Web Servers -4443
Persistence Options
Mode: Active Cookie
Timeout: 3 Days (the length of an inactive Push Session before it times out)
Cookie Name: MS-WSMAN
Scheduling Method: resource based (adaptive)
Idle Connection Timeout: 0
Use Address for SNAT: Unchecked

SSL Properties
SSL Acceleration: Enabled and Reencrypt checked
Certificates: Load the external web services certificate here
Rewrite rules: None
Client Certificates: No Client Certificates required

Advanced Properties
Content Switching: Disabled
HTTP Headre Modifications: None
Port Following: No Port Selected
Enable Caching: Unchecked
Enable Compression: Unchecked
Detect Malicious Requests: Unchecked
Add Header to Request:
Not Available Server:
Not Available Redirection Handling:
Default Gateway:

Complete

Assuming there are physical servers that the VIP is pointing to (again redirecting to port 4443 and 8080) communication should now flow. As key a reminder, make sure the external web services URL resolves internally to the external HLB VIP configured above and you are good.

Comments

Jonas Mellquist

Jonas Mellquist wrote on 01/19/12 3:55 AM

Hi Brian. Just to clarify, could you give a little more insight as to why you choose to create two VIP's?

Why not leave the option on your TMG to keep doing PAT between 443->4443 and 80->8080 (if choosing to run the Autodiscover part of the mobility services unencrypted?)

From what I can gather, the standard/basic options on a KEMP VLM (running software version 6.0-19) are known as:
Persistence Options, Mode: Super HTTP (This equals the Active Cookie option you mention, which again is also known as Cookie based persistence) - is this correct?

Every other guide/manual I've come across has the Scheduling Method set to least connection and not Resource Based (adaptive) - could you explain why you have the latter selected?

I find Dave Howe's article quite hard to understand, especially when using a KEMP HLB! Your article here is the only help I can find on the setup of a KEMP HLB with Lync Web Services and Lync Mobility Services..
Brian Ricks

Brian Ricks wrote on 01/19/12 7:42 AM

@Jonas - The creation of two VIPs was a requirement for my installation because I do not use TMG or any other reverse proxy. Prior to MOBILITY, I did have a single VIP with four services but with the need for the internal communications to hairpin to the external website, the KEMP LB was able to do this for me. Should you have a TMG server having two VIPs would allow you to prevent communications from needing to add extra hops internally.

Regarding the version 6.x - while it sounds correct (my article is using 5.1.x) I have not seen or used 6.x. I have sent a request to KEMP for a firmware upgrade and I will update the article when I know more. The Active Cookie is the concept and if Supper HTTP provides the required stickiness, then you are good.

Least connections assumes all connections are equal - that no one user connection is consuming more resources. Resource Based takes into account the packet load on each server and attempts to distribute the load appropriately. I have found the KEMP LBs to do this rather well.
Jonas Mellquist

Jonas Mellquist wrote on 01/20/12 2:30 AM

Hi again Brian - thank you for your quick and lengthy reply! You're faster than KEMP the support guys and gals :)

A few more questions comes to mind..

1: On the KEMP HLB properties for the services, in the section "Real Server Check Parameters" there are a bunch of options, when choosing which protocol to send the data over.

Am I right in thinking that choosing "TCP Connection Only" and then adding the correct checked port, everything should run correctly in regards to all the four services?

In Dave Howe's article he states that one needs to make sure that the reverse proxy has the Forward host header option on so I guess I don't have to for example choose "HTTPS Protocol" for 4443 and change the URL: parameter. When choosing this option and not adding a URL I get an error stating that the Service (VIP) is Down..
So I'm hoping that things will work with just leaving the option at "TCP Connection Only".

The KEMP manual on setting up ports 443 and 4443 wants me to use the HTTPS Protocol option and add "/abs/handler" as the URL..

2: Again - Assuming there is a TMG server that handles the PAT from 443 -> 4443 and 80 -> 8080 (for anonymous Mobile Autodiscovery). In this situation, what would be the idea / advantage in having two VIP's with two services each? From where I'm sitting one VIP with four services should do the trick, right? In other words - could you elaborate on this sentence:
"Should you have a TMG server having two VIPs would allow you to prevent communications from needing to add extra hops internally."

If you want to IM you already have my SIP URI (e-mail address added to comments). Our Lync federation is working :)

Again - I appreciate your time!
Brian Ricks

Brian Ricks wrote on 01/23/12 10:18 AM

@Jonas - The real server check parameter is a health monitor. Assuming you have configured the Hardware Load Balancer monitoring port on the pool, Lync will expose the specified TCP Port on each server which you can validate is open/available as it will remain idle listening only to your monitor. This communication goes directly to the server IPs.

If you are using TMG the only reason to use two VIPs is to allow mobile communication to go directly to the pool via the HLB rather than TMG --> HLB --> Pool. If you want it all flowing back through the TMG server, then you need 1 VIP and 4 services.

Write your comment



(it will not be displayed)



Leave this field empty: