OCS R2 XMPP Gateway Deployment for Gmail

The purpose of this article is to serve as a lessons-learned addendum to the current primary resource for configuring OCS and GMail federation: the Communication Server team’s official blog post on the subject. Following the detailed steps in that article should get you to a working end-state, but if a specific deployment differs from the directions in any way, sometimes it is hard to tell which of the documented settings are recommendations and which are requirements. I will address each of the steps with additional details that should help explain the requirements and back-ends processes in a bit more detail.
Component Topology
Borrowing the diagram from Microsoft’s documentation, let us look at the different components:

• Gmail
  • The Gmail cloud consistent of a farm of (at last count) 5 different GoogleTalk hostnames overlapped among 3 unique IP addresses. It’s not clear if three of the servers are sharing some type of load-balanced DNS/IP configuration or if some of the hostnames are actually redundant hosts. As with all things ‘cloud’ there isn’t much know about what’s actually inside it, but that is not important when configuring the OCS XMPP server. It is helpful to know the source traffic’s hostnames and IP address when troubleshooting.
    • xmpp-server.l.google.com, 74.125.45.125
    • xmpp-server1.l.google.com, 74.125.155.125
    • xmpp-server2.l.google.com, 74.125.47.125
    • xmpp-server3.l.google.com, 74.125.45.125
    • xmpp-server4.l.google.com, 74.125.45.125 
• Edge Server
  • The normal Edge Server requirements still apply here, so the best practice deployment in a perimeter network with two interfaces on different TCP/IP networks is recommended. Let’s not start cutting corners here; don’t make me write yet another Edge Server article 😉
• XMPP Gateway
  • A single Windows Server with no requirement of multiple network interfaces. A single interface can be used to handle both external (Gmail) and internal (OCS Edge) communications. But if your perimeter network configuration requires two interfaces to properly route traffic in a specific scenario, then 2 separate interfaces can be used and is supported.
  • Network Address Translation is supported, and will be used in this example deployment. But by all means, if a public IP address needs to be assigned directly to an XMPP gateway server interface then communications will work just as well.

Communications Topology
Now we can take a closer look at the actual communication paths utilized end-to-end:

Following the example above, the communications steps for a Gmail user attempting to send an instant message to someone in our contoso.com example OCS organization:

1. Any one server in the GoogleTalk farm will attempt to locate the contoso.com SIP domain services by looking for a specifically defined DNS Service Locator (SRV) record named _xmpp-server._tcp.contoso.com. This record would be configured to point to a DNS Host (A) record for the XMPP gateway’s public FQDN. This can be any name desired. It is recommended to use an A record in the same domain namespace as the SRV record, but this is not a requirement. (Apparently Strict DNS Naming is not required by the XMPP server.) The name xmpp.contoso.comis used in this example.
2. The GoogleTalk server will then attempt a standard TCP connection to xmpp.contoso.com over port 5269. This is not a secured connection, so there are no certificate requirements on this first leg of communications. This connection is typically handled by an external firewall which is performing Network Address Translation (NAT).
3. This request is routed by the firewall to the XMPP server’s single interface which is actively listening on 5269 on its only configured IP address (10.11.12.40). The connection continues to be unsecure.
4. Once the XMPP gateway handles the request it will look at its SIP Configuration to locate an appropriate next hop, which would be configured as the Access Edge FQDN (sip.contoso.com). Based on the DNS configuration of the XMPP server it may be appropriate to configure a local HOSTS entry on the XMPP Server for the Access Edge FQDN to connect directly to the perimeter IP (10.11.12.33). If the public IP is resolved then the communications may fail; this traffic should not be routed outside the firewall and back in, it should stay within the perimeter network.
5. The connection is established with the Access Edge server on it’s Federation listening port of 5061, over MTLS as a certificate is utilized for XMPP Server to Edge Server traffic. The XMPP server must connect to the Access Edge using the Federation port and NOT the internal Edge interface. This is one of the most common deployment mistakes: attempting to configure the XMPP server to communicate with the Edge server’s internal interface.
6. For outbound traffic to GoogleTalk, the Edge Server simply treats the gmail.com SIP domain as any other federated domain. The configuration would denotes that traffic to gmail.com should be xmpp.jds.local in this example. For this portion of communications to properly function there are a few very important aspects to cover:
   • Most importantly a certificate needs to be installed and configured on the XMPP gateway.
     • This is only used for communications between the XMPP and Edge servers, NOT for any external communications with GoogleTalk servers. Thus an internal private CA can be used to request the certificate for the XMPP server, and any root/issuing CA certificates must be imported onto the XMPP server just as would have been done with the Edge server.
     • An easy way to get a certificate on the XMPP server is to use the OCS Certificate Wizard on the Edge server (as the XMPP server does not include the wizard) and then just export and import the certificate with the private key to the XMPP server.
   • Secondly, the certificate must be issued to the XMPP server’s exact hostname.
     • The Microsoft configuration article linked at the top of this blog article discussed that the Primary DNS suffix of the XMPP gateway needs to be configured with something, as an FQDN is required here.
     • What the article does not clarify is that XMPP server’s FQDN must utilize the actual server hostname; you cannot just select any secondary name for the XMPP server and configure the certificate, DNS resolution, and the Edge server’s Allow list entry to just anything. More simply stated: the XMPP server’s configured FQDN, certificate CN (or SAN entry) and the Edge server’s Allow list entry for gmail.com must all be set to the actual server’s fully qualified hostname. Because the XMPP server hands this name out during communications it is a hard requirement
   • Lastly, if a single XMPP server FQDN configuration is attempted, instead of using separate private and public as in this example, then:
     • Microsoft’s article states that the public FQDN could be used here instead, but the external firewall would need to be configured to allow outbound traffic from the Access Edge server to loop back into the firewall and then connect to the XMPP server over 5061. Normally only traffic destined to 5269 would be allowed in from the Internet.
     • This configuration is least desirable as it is best practice to keep all XMPP<>Edge communications internal, just as discussed above in step #4. But since the leg of the communications is encrypted then routing it out to the Internet temporarily does not impose any additional security threat.
7. The XMPP server uses the XMPP configuration to locate gmail.com services from it’s Allowed Domain List by resolving the known SRV record _xmpp-server._tcp.gmail.com. Currently the xmpp-server.l.google.comrecord is configured as the highest priority (set to the lowest value or 5 versus 20 for the other hosts). The XMPP server then connects to that host to complete the entire communication path.
8. Success!

Caveats
There are a few items in the current implementation of the XMPP services which should be understood:

• Only a single SIP domain per OCS organization can be configured. This limitation comes from the fact that (1) the XMPP server configuration only has the ability to support a single OCS SIP domain for gateway services and (2) the Edge server Allow list can only point to a single next-hop for the gmail.comSIP domain. So even if multiple XMPP server instance were deployed to support each desired OCS SIP domain, the OCS organization’s single Access Edge server could only point to one of those XMPP servers. There is currently no workaround to this limitation, so typically only the primary SIP domain is configured XMPP services.
• Originally only gmail.com addresses were supported, but in January 2010 Microsoft released a hotfix for the XMPP server which adds support for the googlemail.com SIP domain as well. No configuration changes are necessary on the XMPP server itself after applying the update as it will automatically use the defined route to gmail.com for any communications destined for googlemail.com contacts. But additional configuration is required on the Edge server, as an additional entry must be added to the Allow list properties tab for googlemail.com to point to the same XMPP internal FQDN that was used for the original gmail.com entry.

Troubleshooting
As with anything OCS-related, know where the firewalls are and what traffic they are allowing/blocking. Nearly every deployment I have been involved with almost always has some blocked port, misconfigured policy rules, fat-fingered port number, or some other issue which prevents servers from communicating over the desired ports. If at any point you are struggling it is never a bad idea to eyeball the firewall polices and network diagrams one more time. Occasionally even the smallest mistake can completely prevent communications. For example, I once ran into an issue where OCS was configured to use lm.domain.com (as in Live Meeting) for one of the FQDNs but the hosting provider read the request to create an external DNS record as im.domain.com (as in Instant Messaging) due to the font that was used. In many sans serif fonts an uppercase ‘I’ looks identical to a lowercase ‘l”. < See what I mean?
To test connectivity to various service when testing traffic filtering rules, start with the following:
Name Resolution
Verify that lookup of the GoogleTalk servers is functioning:

C:>nslookup -type=srv _xmpp-server._tcp.gmail.com
Non-authoritative answer:
_xmpp-server._tcp.gmail.com SRV service location:
priority = 20
weight = 0
port = 5269
svr hostname = xmpp-server2.l.google.com
_xmpp-server._tcp.gmail.com SRV service location:
priority = 20
weight = 0
port = 5269
svr hostname = xmpp-server1.l.google.com
_xmpp-server._tcp.gmail.com SRV service location:
priority = 20
weight = 0
port = 5269
svr hostname = xmpp-server3.l.google.com
_xmpp-server._tcp.gmail.com SRV service location:
priority = 5
weight = 0
port = 5269
svr hostname = xmpp-server.l.google.com
_xmpp-server._tcp.gmail.com SRV service location:
priority = 20
weight = 0
port = 5269
svr hostname = xmpp-server4.l.google.com

Verify that the XMPP server’s SRV and A records exist:

C:>nslookup -type=srv _xmpp-server._tcp.contoso.com

Non-authoritative answer:
_xmpp-server._tcp.contoso.com SRV service location:
priority = 0
weight = 0
port = 5269
svr hostname = xmpp.contoso.com
C:>nslookup xmpp.contoso.com

Non-authoritative answer:
Name: xmpp.contoso.com
Address: 12.34.56.78

Port Connectivity
Using telnet and netstat commands a number of test can be performed to validate end-to-end communications are correctly allowed. When using telnet to connect to specific ports if a blank window immediately appears that is an indication of a successful connection. A failed connection will be reported as ‘Connect failed’ after a few seconds. Be aware that return traffic needs to allowed for a successful connection, so often the return packets are accidently filtered by a firewall configuration causing this error.
From the XMPP server telnet to each of the GoogleTalk XMPP listenting ports to verify connectivity.

C:>telnet xmpp-server.l.google.com 5269
C:>telnet xmpp-server1.l.google.com 5269
C:>telnet xmpp-server2.l.google.com 5269
C:>telnet xmpp-server3.l.google.com 5269
C:>telnet xmpp-server4.l.google.com 5269
 

Perform a similar test from an external host to verify inbound communications to the XMPP server:

C:>telnet xmpp.contoso.com 5269

From the XMPP server test connectivity directly to the Access Edge service:

C:>telnet edge.jds.local 5061
 

From the Edge server test connectivity directly to the XMPP server:

C:>telnet xmpp.jds.local 5269

Active Connections
If all test appear to work but IM connections to or from gmail.com users is still not working, active connections can be searched for on the XMPP server to validate that the remote GoogleTalk servers are attempting to connect.
From the XMPP server search for active TCP connections to the XMPP listening port:

C:>netstat –ano | findstr 5269
TCP 10.11.12.40:5269 0.0.0.0:0 LISTENING 1780
TCP 10.11.12.40:5269 10.11.12.40:62325 CLOSE_WAIT 1780
TCP 10.11.12.40:5269 33.99.141.69:37617 ESTABLISHED 1768
 

And to look for connections from the Edge server:

C:>netstat –ano | findstr 5061
TCP 10.11.12.40:5061 0.0.0.0:0 LISTENING 1780
TCP 10.11.12.40:5061 10.10.10.50:3690 ESTABLISHED 3688
TCP 10.11.12.40:62329 10.11.12.40:5061 TIME_WAIT 0