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.
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.
Looking at communication from a phone via cellular and WiFi then looks like so:
Phone IP (184.108.40.206) --> Ext AutoDiscover (220.127.116.11:443) --> Ext Web Services URL (18.104.22.168:443) --> HLB (10.10.10.20:443) --> Lync Pool External Web Services (10.10.10.50:4443)
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:
Service Type: HTTP/HTTPS
L7 Transparency: Disabled
Real Server Check Parameters: Optional but recommended
Service Nickname: Lync Web Servers -4443
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 Acceleration: Enabled and Reencrypt checked
Certificates: Load the external web services certificate here
Rewrite rules: None
Client Certificates: No Client Certificates required
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:
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.