locked
Can't get a Polycom CX600 connected through Cisco-VPN RRS feed

  • Question

  • Hello everybody.

    We have got massive problems connecting our Polycom CX600 to our Lync Server through VPN.

    The VPN-connection is configured in a cisco ASA and works "as normal". With an client PC in the VPN-network i can connect without any problems with the Lync client to our server over the internal address.

    If I put the CX600 in our internal network i can also connect as easy as normal to the Lync server (via ext/pin and via USB). But - I dont know why, if i put the phone in the VPN network, it cant connect. Neither though ext/pin nor through USB-tethering.

    So in one sentencte: in the internal network everything is fine.

    Through VPN
    PC Lync-Client signs in correctly.

    CX600:
    PIN / EXT: The phone is connecting a while, gets a correct time, tries to connect to Lync server. Then "An account matching this phone number cannot be found. Please contact your support team."
    USB: On the PC Lync is connected to the internal server (lync01.mydomain.tld): When the phone is connected an we provide correct credentails. Account: user@mydomain.tld, User: DOMAIN\user, PWD: correct PWD. Then after a short amount of time, we get the following error-message:
    "Cannot sign in. Please verify your sign-in address, domain\user name, and password, and try again. Please verify that the Domain entered @mydomain.tld is correct."

    Additional notes: -time is synced correctly, certificate web service is found (was a problem before, covered through giving option 120 and 43 in the ASAs dhcp)

    Another thing we could see in the logs, was the following, maybe there could somewhere be a hint?

    $$begin_record
    LogType: diagnostic
    Severity: information
    Text: Response successfully routed
    SIP-Start-Line: SIP/2.0 401 Unauthorized
    SIP-Call-ID: ed4764a9358a8857fc84e4eab9740e72
    SIP-CSeq: 2 REGISTER
    Peer: 172.16.101.101:49165
    Data: destination="Unknown"
    $$end_record

    And: I already looked through

    http://social.technet.microsoft.com/Forums/en-IE/ocsvoice/thread/068113fd-edeb-4733-8827-809aa977648c

    http://blog.schertz.name/2010/12/externally-provisioning-lync-phone-edition-3/

    http://blog.schertz.name/2010/12/configuring-lync-server-for-phone-edition-devices/

    and

    http://www.shudnow.net/2011/05/02/configuring-lync-dhcp-using-cisco-dhcp-servers-vlan-and-pin-auth/

    (and many other reasearch)

    But maybe I am missing something? Where can I look, what could be the fault? Must the VPN (172...) be somehow authorized to access?

    Thanks for your help.


    • Edited by Jamilian Friday, April 20, 2012 10:14 AM
    Friday, April 20, 2012 9:10 AM

Answers

  • Hi!


    We've got it.


    In the Microsoft ticket we are gone through the typical process of gathering a network-trace. And in this trace it was possible to see, that thate are quite many TCP-packages which are retransmitted. Further investigation showed that the retransmission-packages had nearly every time a size of 1438 Bytes or bigger.


    So we checked the maximum size which can be transmitted without the need to fragment it (ping <target> -l <size(Byte)> -f) [-l (its a small L) is the parameter to define the lenght of the sent package, -f sets the "do-no-fragment"-Bit.] And then we checked the max. size using -l 1200, -l 1300, -l 1400 and saw that the 1400 Byte package would have to be fragmented. Finally we could see, that our maximum MTU has been 1364 Bytes through the VPN-tunnel.

    And the packages which haven't been correctly delivered seem to be the reason for the authentication-failures.


    The solution(s):


    First solution (not as goos as the other but working)

    Reducing the MTU for all interfaces on the Domain-Controllers and the Lync-Frontend-Server to a value round about 50 lower than the package-size (we reduced the MTU to 1300).

    The registry-key and value to do this:


    HKLM\SYSTEM\CurrentControlSet\services\tcpip\Parameters\Interfaces\<Interface>\MTU

    Type: DWORD

    Value: (decimal) <MTU size> (here 1300)


    Link: http://support.microsoft.com/kb/314053/en-us (works also on W7 / WS2008R2)

    And after setting the value... reboot or deactivate and reactivate the interfaces.



    Second solution (the better one but i didn't check this actually)

    Activating the MTU Black Hole Detection. In short as I understood: The Black Hole Detection checks if there are retransmitted packages on a tcp-connection if the packages can be delivered with a reduced MTU (536 Bytes). If they can be delivered the packages will be sent with this MTU on the connection. In addition to that the maximum number of retransmissions is increased.

    The registry-key and value to do this:

    HKLM\SYSTEM\CurrentControlSet\services\tcpip\Parameters\EnablePMTUBHDetect

    Type: DWORD

    Value: 1 (0 is deactivated)

     

    Link: http://technet.microsoft.com/en-us/library/cc960465.aspx



    And after setting the value... reboot!


    I think - thats it.

    The phone and all other Lync phones are signing in as usual through the VPN-tunnel now.


    Again many thanks to everyone involved in this issue.



    • Edited by Jamilian Tuesday, June 5, 2012 1:22 PM now.
    • Marked as answer by Jamilian Tuesday, June 5, 2012 1:22 PM
    Tuesday, June 5, 2012 1:10 PM

All replies

  • I just made some new protocols to find the error but i cant get forward.

    And because it seems to have to do with credentials, here more specific information.

    Before you ask - yeah the CX600 has been logged in one time internally.

    Lync-FE is: lync01.mysubdomain.mydomain.tld

    Lync-Edge (even it it not should be necessary): lync02.mysubdomain.mydomain.tld

    SIP-Domain: user.name@mydomain.tld

    so I have to correct myself - For logging in with USB it is

    Account: user.name@mydomain.tld

    User: mysubdomain\username

    PWD: correct

    And here some log-outputs:

    Is there anything missing in the AD? Or do I have maybe to configure something in the FE itself?

    Friday, April 20, 2012 10:05 AM
  • Hello,

    i just stumbled about 'admin' in Your logs.  Have You tried it with a user who has administrative privileges? I Thought i remembered that this could cause some trouble. So maybe just try it with a user without extended privileges.
    Friday, April 20, 2012 10:45 AM
  • please try to use this credentials to log in on the phone

    Account: user.name@mydomain.tld

    User: username@mysubdomain

    PWD: correct


    regards Holger Technical Specialist UC

    Friday, April 20, 2012 10:48 AM
  • I just tried it with a user without any admin privileges, same error (also in the logs).

    And also changing the user to username@mysubdomain didn't help...

    Don't know where the problem could be.

    I'm especially wondering about that everything works fine in our internal network, but not in the VPN-remote net. Well I see its another IP-range but could that become a problem for authentification?

    Friday, April 20, 2012 11:35 AM
  • Are you shure, that the phones get all necessarry information from DHCP. Because I had on one site the same problem and I coudl see in my wireshark trace the phone didn't get the right information from DHCP because of a misconfiguratuion of the cisco Lan port.


    regards Holger Technical Specialist UC


    Friday, April 20, 2012 12:09 PM
  • I will try to trace a DHCP-package and look if there is anything necessary.

    But shouldn't it be unnecessary if I tether the phone to the PC?

    And just to be sure - I configured actually dhcp option 43 and 120 like explained here http://www.shudnow.net/2011/05/02/configuring-lync-dhcp-using-cisco-dhcp-servers-vlan-and-pin-auth/

    Or is it a must to configure the VLAN-Option in the ASA also?

    I will check it anyways.

    Friday, April 20, 2012 12:18 PM
  • As i understand it the Lync Client computer is configured right to log in also through VPN so it can reach the server but the CX600 can only contact in the internal network not in the VPN.
    Maybe it seems to be necessary requirement somehow to configure the CX600 directly itself to get connectivity to the server for successfully log in also trough VPN.
    Friday, April 20, 2012 12:19 PM
  • Are we talking about a site-to-site VPN, or a client-based VPN scenario?  If a Windows workstation is using a soft client to establish a VPN connection then the phone will not work over the VPN in this scenario.

    1. PIN Authentication is only supported internally and cannot be used externally
    2. A USB-tethered phone still communicates with the Lync server via it's own Ethernet connection, which will not be on the VPN in this scenario.  The phone will perform it's own standard lookups and then connect to an Edge Server (if available).

    you would need to define a site-to-site VPN on the router in the specific location so that the phone itself is able to be passed a DHCP lease in the VPN scope and be able to communicate directly with the internal servers.


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    Friday, April 20, 2012 1:26 PM
  • I had this problem also with phones thetered via usb with a PC. But you can also try to login the phone on the main office an test this phone in your branche office

    regards Holger Technical Specialist UC


    Friday, April 20, 2012 1:37 PM
  • Are we talking about a site-to-site VPN, or a client-based VPN scenario?  If a Windows workstation is using a soft client to establish a VPN connection then the phone will not work over the VPN in this scenario.

    1. PIN Authentication is only supported internally and cannot be used externally
    2. A USB-tethered phone still communicates with the Lync server via it's own Ethernet connection, which will not be on the VPN in this scenario.  The phone will perform it's own standard lookups and then connect to an Edge Server (if available).

    you would need to define a site-to-site VPN on the router in the specific location so that the phone itself is able to be passed a DHCP lease in the VPN scope and be able to communicate directly with the internal servers.


    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP

    We are talking here about a site-to-site VPN, the VPN is established right through the cisco ASA. The phone is able to communicate with the Lync FE. Also I can see in the logs (and the ressourcemonitor) that the Phone is communicating with the FE (looking at the screenshots).

    Also the Phone gets an ip in the VPN scope 172.16.101.x in this case, which i can ping from the FE.

    But for one reason the phone doesnt seem to get a right domain-authorisation. But where is the difference of being in the VPN scope and being "really" internal regarding the domain-login? I really can't explain it to myself...

    Friday, April 20, 2012 2:06 PM
  • Have just done this, logged in internally (via USB), phone connected without any problems.

    Disconnected it, brought it to the remote site, connected it, tries to login by itself -> again:

    Cannot sign in. Please verify your sign-in address, domain\user name, and password, and try again. Please verify that the domain entered @mydomain.tld is correct.

    Friday, April 20, 2012 2:24 PM
  • Hm, normal I could say, maybe the phone didn't get the DHCP settings. Use wireshark on the phone site to see if your phone gett all DHCP information. Also you can look on the IIS log to see if he phone request a certificate.

    Also the search for the NTP service should on the initializing of the phone very quick.


    regards Holger Technical Specialist UC

    Saturday, April 21, 2012 7:11 PM
  • Hi,

    As the message shows it failed to provide valid credentials by TLS transportion, I suggest using Set-CsUCPhoneConfiguration to set SIPSecurityMode to Low or Medium level to test the issue.

    SIPSecurityMode
    Specifies the level of security that the server applies to SIP sessions initiated by a UC phone.
    Valid values are:
    Low (allow any type of authorization or transport).
    Medium (NTLM or Kerberos is required for user authentication).
    High (NTLM or Kerberos is required for user authentication and TLS is required for SIP connections).
    The default value is High.

    http://technet.microsoft.com/en-us/library/gg413042.aspx

    In addition, please also try to use Netmon to get the detailed informtion.
    Regards,
    Kent

    • Proposed as answer by Kent-Huang Tuesday, May 1, 2012 2:33 AM
    • Unproposed as answer by Jamilian Wednesday, May 9, 2012 2:26 PM
    Monday, April 23, 2012 6:48 AM
  • Hi,

    As the message shows it failed to provide valid credentials by TLS transportion, I suggest using Set-CsUCPhoneConfiguration to set SIPSecurityMode to Low or Medium level to test the issue.

    SIPSecurityMode
    Specifies the level of security that the server applies to SIP sessions initiated by a UC phone.
    Valid values are:
    Low (allow any type of authorization or transport).
    Medium (NTLM or Kerberos is required for user authentication).
    High (NTLM or Kerberos is required for user authentication and TLS is required for SIP connections).
    The default value is High.

    http://technet.microsoft.com/en-us/library/gg413042.aspx

    In addition, please also try to use Netmon to get the detailed informtion.
    Regards,
    Kent

    Unfortunetly this didn't help either.

    I can't go on with testing actually because there are other things on my plan right now - but I will go on here. Have got also a ticket with MS for this which is pending actually.

    Wednesday, May 9, 2012 2:30 PM
  • Hi,

    Please share with us if there is any update on the issue. In addition, a similar issue just for your reference:

    http://social.technet.microsoft.com/Forums/en-US/ocsvoice/thread/068113fd-edeb-4733-8827-809aa977648c/

    Regards,

    Kent

    Monday, May 14, 2012 2:16 AM
  • Just to give a status to this - we are working on this with Microsoft, but it could take some time. We will see.
    Tuesday, May 29, 2012 7:39 AM
  • Hi!


    We've got it.


    In the Microsoft ticket we are gone through the typical process of gathering a network-trace. And in this trace it was possible to see, that thate are quite many TCP-packages which are retransmitted. Further investigation showed that the retransmission-packages had nearly every time a size of 1438 Bytes or bigger.


    So we checked the maximum size which can be transmitted without the need to fragment it (ping <target> -l <size(Byte)> -f) [-l (its a small L) is the parameter to define the lenght of the sent package, -f sets the "do-no-fragment"-Bit.] And then we checked the max. size using -l 1200, -l 1300, -l 1400 and saw that the 1400 Byte package would have to be fragmented. Finally we could see, that our maximum MTU has been 1364 Bytes through the VPN-tunnel.

    And the packages which haven't been correctly delivered seem to be the reason for the authentication-failures.


    The solution(s):


    First solution (not as goos as the other but working)

    Reducing the MTU for all interfaces on the Domain-Controllers and the Lync-Frontend-Server to a value round about 50 lower than the package-size (we reduced the MTU to 1300).

    The registry-key and value to do this:


    HKLM\SYSTEM\CurrentControlSet\services\tcpip\Parameters\Interfaces\<Interface>\MTU

    Type: DWORD

    Value: (decimal) <MTU size> (here 1300)


    Link: http://support.microsoft.com/kb/314053/en-us (works also on W7 / WS2008R2)

    And after setting the value... reboot or deactivate and reactivate the interfaces.



    Second solution (the better one but i didn't check this actually)

    Activating the MTU Black Hole Detection. In short as I understood: The Black Hole Detection checks if there are retransmitted packages on a tcp-connection if the packages can be delivered with a reduced MTU (536 Bytes). If they can be delivered the packages will be sent with this MTU on the connection. In addition to that the maximum number of retransmissions is increased.

    The registry-key and value to do this:

    HKLM\SYSTEM\CurrentControlSet\services\tcpip\Parameters\EnablePMTUBHDetect

    Type: DWORD

    Value: 1 (0 is deactivated)

     

    Link: http://technet.microsoft.com/en-us/library/cc960465.aspx



    And after setting the value... reboot!


    I think - thats it.

    The phone and all other Lync phones are signing in as usual through the VPN-tunnel now.


    Again many thanks to everyone involved in this issue.



    • Edited by Jamilian Tuesday, June 5, 2012 1:22 PM now.
    • Marked as answer by Jamilian Tuesday, June 5, 2012 1:22 PM
    Tuesday, June 5, 2012 1:10 PM