FQDN VCS integration with Lync 2010

[jmecklenburg]

Hi Team

I working on a demo integration VCS with Lync, the software version is VCS 7.2 and Lync 2010, VCS with demo lincense. The integration is over TLS, the CA certificate and server certificate it's OK, but the negotiation TLS fail. When i see wireshark on  Lync FE server see the TLS request form VCS sending the IP address not the FQDN. and we think that it's the problem.

We have any issue with this? some similar?

Regards.       

[awinter2]

Javier,

where exactly in the TLS handshake in WIreshark are you seeing the VCS sending its own IP address instead of its FQDN? In the server certificate installed on the VCS, does the Subject Name and/or Subject Alternative Name contain the VCS FQDN?

Could you perhaps send me the packet capture file and server certificate from the VCS over PM so that I can take a closer look?

Thanks,

Andreas

[jmecklenburg]

Hi Andreas thanks for your help

As can i see in wireshark, the VCS sended the TLS invite, the FE answer with CA and the VCS immediately close the TLS connection. The VCS send the invite  TLS with the IP address not the FQDN.

The server certificate was installed in the VCS, the subjet name is the vcs fqdn and the alternative subjet name is in blank.

Let me take the capture and send us.

Thanks!

[Martin Koch]

First of all, please follow the deployment guides for the integration (lync+certificates) + the admin guide.

You find them here: http://www.cisco.com/en/US/products/ps11337/tsd_products_support_series_home.html

Is DNS properly working on the VCS (best is to use the DNS servers used also on your lync setup),

are other things like ntp working fine?

Is the FQND of the VCS properly configured and resolvable for all? See the

Cisco VCS Deployment Guide: Microsoft Lync 2010 and Cisco VCS X7.2:

Note that: 

*  the Localhostname concatenated with DNS Domainname is the routable FQDN of thisV CS. 

*  iftheseitemsarenotconfiguredandtheconnectionbetweenLyncserverandVCSisTLS,then although the neighbor zone goes active and VCS can send messaging to Lync server, Lync server will never open a TLS connection back to VCS, resulting in no calls from Lync to VCS and other strange behavior. 

I do not think that the demo vcs is the reason for the problem, though I never tried it.

But be aware that some features (like using ICE together with the VCS-E (which is also

needed for lync users behind edge), proper deployment (at that is using findme) will not

work without the proper licenses which you can not get for the virtual demo vcs

[awinter2]

Javier,

normally, in the case where the VCS initiates the TLS connection, VCS would send a Client Hello to the far end, where the far end should respond with a Server Hello.

I still don't understand what you mean by "the FE answer with CA' and 'The VCS send the invite TLS with the IP address not the FQDN'. The FE should send a Server Hello containing its server certificate, not a CA certificate. With your second statement, do you mean that when the VCS sends a Client hello, that the Subject Name in that Client hello contains the IP address of the VCS rather than the FQDN?

As mentioned, I think it would be more helpful if you could send me the network capture and VCS server cert by PM so that I can take a closer look. Also let me know the IP address of the VCS and the FE.

Thanks,

Andreas

[jmecklenburg]

Hi and thanks guys for your help.

I have the capture, when the VCS sending the "client hello" the FE respond with a "server hello, certificate certificate request, server rhello done". after that the VCS respond with a alert message (level: Fatal, Description: Decode Error)... no more log and then the message repeat.

the fqdn it's configured ok VCS/System/DNS, and the DNS it's working correct.

Andreas i send you the capture by PM

[awinter2]

Javier,

I suspect that the VCS you are using is running non-encrypted VCS software, is this correct? To check this, go to Maintenance > Option keys and verify that 'Encryption' is not listed in the 'Active options' field under 'System information'.

If you are in fact using non-encrypted VCS software, it is very likely that you are affected by CDETS CSCub63112, which is a bug that causes problems when the VCS attempts to establish SSL/TLS connections to remote parties. This bug will be addressed in the upcoming X7.2.2 software for the VCS, which should be released within a few weeks time.

- Andreas

[jmecklenburg]

Andreas

Yes, I don't have encryption over "Active Options"

We have other solution for the integration?

Regards.

[awinter2 · Accepted solution]

Javier,

While waiting for X7.2.2 to be released, you could configure the VCS B2BUA and Lync to communicate over SIP TCP rather than TLS.

On the VCS side, on the B2BUA configuration page, the only changes you have to make is to configure the 'OCS/Lync signaling destination port' to '5060' and 'OCS/Lync signaling transport' to 'TCP'.

On the Lync side, you have to do the following:

- Configure the Lync registrar pool to listen on TCP port 5060:

Set-CsRegistrar "registrar:feppool.example.com" –SipServerTcpPort 5060

- Create a trusted application pool and trusted application for VCS (Example VCS IP address 10.10.10.10, VCS FQDN vcs.example.com), communicating with Lync on TCP port 65072 (Default B2BUA port for Lync communication):

New-CsTrustedApplicationPool -Identity vcs.example.com -ComputerFqdn 10.10.10.10 -Registrar feppool.example.com -site 1 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true

New-CsTrustedApplication -ApplicationId VCStcp -TrustedApplicationPoolFqdn vcs.example.com -Port 65072

- If needed, create a static SIP route for domain 'vc.example.com' from Lync towards the VCS B2BUA:

$Route1=New-CsStaticRoute -TCPRoute -Destination "10.10.10.10" -MatchUri "vc.example.com" –Port 65072

Set-CsStaticRoutingConfiguration -Identity global -Route @{Add=$Route1}

- Finally, enable the new topology:

Enable-CsTopology

Once you have completed all configuration steps on both VCS and Lync, you should restart the OCS/Lync B2BUA.

Please note that many of the command parameters above should be changed to fit your environment, for instance registrar pool FQDN and site ID, VCS IP address/FQDN, static SIP route domain and so forth. The above commands are therefore simply examples on how the syntax should be when setting up SIP TCP-based signaling between VCS and Lync.

Once X7.2.2 is out, I recommend you upgrade to this version and re-enable SIP TLS communication between VCS and Lync, since this is the preferred and recommended integration method.

Hope this helps,

Andreas