locked
external clients desktop sharing fails RRS feed

  • Question

  • After reading through various articles and forum posts I am desperate enough to contribute my first post...

    The Problem:

    We have successfully implemented a Lync 2010 infrastructure.

    • Internal to Internal works perfect 
    • Internal to external (or vice versa) works perfect except for desktop sharing (Audio /Video works perfect)

    (with external being an internal user in an external network)

    I tried to narrow down the problem and found the following issues:

     

    23; reason="Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote";CallerMediaDebug="application-sharing:ICEWarn=0x800029,LocalSite=192.168.18.105:5388,LocalMR=xxx.xxx.xxx.xxx:3478(public IP Adress from AV.xxx.de) ,RemoteSite=192.168.10.73:5378,RemoteMR=xxx.xxx.xxx.xxx:56119 (public IP Adress from AV.xxx.de) ,PortRange=5350:5389,RemoteMRTCPPort=56119,LocalLocation=1,RemoteLocation=2,FederationType=0"

     

    So basically a client connects from behind a NAT device to the external IP of the edge av interface and the internal client tries to connect to the same external ip?

    Is that meant to be that way?

     

    Second issue (or same issue but different perspective) same scenario(but network Sniffer on the firewall):

    request reaches FW:

    50.436292 port2 in Guest IP:35962 -> external AV Edge IP:59676: syn 2844552579

    request routed through FW to the internal DMZ IP:

    50.436857 Lync-extern out Guest IP:35962 -> 172.16.13.204:59676: syn 2844552579

    session gets resetted:

    50.437046 Lync-extern in 172.16.13.204:59676 -> Guest IP:35962: rst 0 ack 2844552580

    This repeats very often till both clients get a notice about "Network issuses.

     

    On the Edge Server I did an netstat -oa and found Port 59676 to be listening (TCP)

     

    I read so much in the last days that I am totally confused by now and I think the documentation on tech net is faulty somehow.

    (at least regarding port 50.000 ->59.999)


    Maybe the issue is DNS related (we got split DNS in place)?

     

    Any thoughts helping me out would be appreciated!

    Thanks Gunni

     

     


    Who needs a signature?
    Friday, August 26, 2011 2:17 PM

Answers

  • Hello Gunni,

    please can you tell what is the vendor, model and firmware of your firewall? Are there any kind of "deep inspection" features enabled in the configuration of the firewall.

    I am asking, as we have seen similar issues with an RST that seemed to come from the Lync Edge Server, but in fact the connection reset was done by the firewall. In the mentioned case the firewall is a Juniper, model SSG-5.

    Two flow related settings activated in the configuration caused the issue, leading exactly to the ms-client-diagnostic: reason="Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote"

    “flow tcp-seq-check” -                  (TCP Sequence Check)

    “flow tcp-syn-check” -                  (TCP SYNCRO Check)

    Please check if your firewall has some similar or identical settings activated!

    A lot of time, we investigated the Edge Server for any issues, - we even replaced it with a new one built from the scratch. Nothing helped, till we start looking closer at the firewall and disabled the settings mentioned above. I remember that we thought the RST comes from the Lync Edge on the first look in NetworkMonitor and Wireshark. But when we started watching the Juniper reports, and comparing the time-stamps we realized that the connection was closed first by the firewall, not the Lync Server.

    If your firewall offers a reporting feature (via webinterface, or SNMP, etc.) I recommend you to take a close look to check if the connection is closed here first.

    Thanks and greetings from Berlin,
    Jan


     


    Jan Boguslawski | Technical Product Manager - snom OCS / UC Edition | MCITP: EA, MCTS OCS, MCTS EXCHANGE | snom technology AG, Berlin | www.snom.com | http://ocsphoneguy.blogspot.com
    • Marked as answer by GunniO Friday, September 9, 2011 12:02 PM
    Thursday, September 8, 2011 4:22 PM

All replies

  • When A/V calling works but Desktop Sharing does not the first place to look is at the firewall rules to validate that your media port ranges are opened for both UDP and TCP traffic.  By default A/V transmits over UDP (although TCP can also be used) while Desktop Sharing only supports TCP connections.  So in your scenario it is likely that TCP traffic is blocked somewhere in the media path.


    Jeff Schertz, Microsoft Solutions Architect - Polycom | Lync MVP
    Friday, August 26, 2011 5:19 PM
  • The following article gives solution about the issue, hoping it can help you:

    http://support.microsoft.com/kb/2386684


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Monday, August 29, 2011 6:47 AM
  • Dear Jeff,

    as I tried to point out the package obviously reaches the lync server since the lync sends the RST.

    Or do you think that it sends the RST because some other connection is not functioning properly?

    Thanks


    Who needs a signature?
    Monday, August 29, 2011 10:13 AM
  • Dear Sean,

    I read through the article and tried to understand what it means for our environment:

    LyncFE-meet-http_vip port2(wan)/xxx.xxx.xxx.77 80/tcp 192.168.11.160 8080/tcp    
    LyncFE-meet-https_vip port2(wan)/xxx.xxx.xxx.77 443/tcp 192.168.11.160 4443/tcp    

    In your example the port range 1025:65000 is used while we use the default port range 5350 to 5389.

    Do we have to open those ports as well?

    That should be enough?

    Since we do not use office 365 online that rest doe not apply for us?

    Thanks!

     


    Who needs a signature?
    Monday, August 29, 2011 10:20 AM
  • Some additional information:

    I installed Wireshark on the Edge Server and did some traceing:

    463    133.204238    external.client.domain.de    172.16.13.204    TCP    62    52616 > 56245 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1

    464    133.204294    172.16.13.204    external.client.domain.de    TCP    54    56245 > 52616 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

    From my point of view, this shows that the tcp traffic reached the edge server on a port in the chosen range.

    The RST Package shows: Header checksum: 0x0000 [incorrect, should be 0xc20e (maybe caused by "IP checksum offload"?)]

    Got no idea what that means though...

    I really hope someone can offer some help..

    Thanks!


    Who needs a signature?
    Monday, August 29, 2011 2:03 PM
  • Was that port in the candidate list you sent to them?  Can you provide the candidate list you sent to them.  And how manyn edge servers do you have in your deployment?

    Also not that the external edge requires 443,5061, 50k-59.999k both  ways udp&tcp i might have missed one.

    If your firewall is properly configure can you disable any software firewall or antivirus software thats on your edge and try again? 


    BBB
    Monday, August 29, 2011 11:50 PM
  • Hello Indubious,

    the testing involved my notebook in a public Network and a colleague being in the company network.

    First we chatted, tested A/V and then tried Desktop Sharing.

    We have a single consolidated edge deployment.

    Firewall is configured to permit 443 (TCP), 5061(UDP and TCP), RTP 50.000-59.999 (TCP and UDP) and STUN 3478 (UDP) incoming and outgoing.

    Software Firewall is not in use.

    Best Regards

    Gunni


    Who needs a signature?
    Tuesday, August 30, 2011 10:58 AM
  • I can run a couple tests with you if you'de like.  But it still looks like a firewall issue from the snipets you sent.
    BBB
    • Proposed as answer by Sean_Xiao Friday, September 2, 2011 1:34 AM
    • Unproposed as answer by GunniO Monday, September 5, 2011 11:35 AM
    Wednesday, August 31, 2011 4:01 PM
  • Hi Indubious,

    testing would be great.

    Please tell me how to get in touch / how to test.

    btw: Today we tried to connect external external desktop sharing and everything worked.

    Maybe someone has got a hint what differs between internal->external and external ->external connection attepmts?!

    Best Regards

    Gunni


    Who needs a signature?
    • Edited by GunniO Friday, September 2, 2011 7:29 PM
    Friday, September 2, 2011 7:12 AM
  • What clients did you use to test external-internal connectivity and between which clients does it work externally-externally?
    Which OS version do they have?
    Certified IT Professional Lync Server 2010 / Exchange 2007 - http://www.uwictpartner.be
    If you think my post is the answer to your question, please mark it as answer so future visitors can easily find it.
    Tuesday, September 6, 2011 7:02 AM
  • Dear Ruben,

    as I wrote earlier, external to external works smoothly, but I think clients use direct connect in this case.

    The OS is Windows7 on a notebook which works internally.

    For testing we just used the notebook in an external connected LAN Port (DSL)

    Best Regards

    Gunni


    Who needs a signature?
    Tuesday, September 6, 2011 6:49 PM
  • Dear GunniO,

    >> as I wrote earlier, external to external works smoothly, but I think clients use direct connect in this case.
    Clients try to connect directly but if this fails the Edge is used.

    >> The RST Package shows: Header checksum: 0x0000 [incorrect, should be 0xc20e (maybe caused by "IP checksum offload"?)]
    Go to device manager on the edge and the device properties for each NIC. On the Advanced tabpage disable any setting involving TCP checksum offloading and try again.

    >> The OS is Windows7 on a notebook which works internally.
    As I wrote earlier, and I speak from experience, you should never test with only one machine for such issues.

    Best regards


    Certified IT Professional Lync Server 2010 / Exchange 2007 - http://www.uwictpartner.be
    If you think my post is the answer to your question, please mark it as answer so future visitors can easily find it.
    Wednesday, September 7, 2011 6:20 AM
  • Hello Gunni,

    please can you tell what is the vendor, model and firmware of your firewall? Are there any kind of "deep inspection" features enabled in the configuration of the firewall.

    I am asking, as we have seen similar issues with an RST that seemed to come from the Lync Edge Server, but in fact the connection reset was done by the firewall. In the mentioned case the firewall is a Juniper, model SSG-5.

    Two flow related settings activated in the configuration caused the issue, leading exactly to the ms-client-diagnostic: reason="Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote"

    “flow tcp-seq-check” -                  (TCP Sequence Check)

    “flow tcp-syn-check” -                  (TCP SYNCRO Check)

    Please check if your firewall has some similar or identical settings activated!

    A lot of time, we investigated the Edge Server for any issues, - we even replaced it with a new one built from the scratch. Nothing helped, till we start looking closer at the firewall and disabled the settings mentioned above. I remember that we thought the RST comes from the Lync Edge on the first look in NetworkMonitor and Wireshark. But when we started watching the Juniper reports, and comparing the time-stamps we realized that the connection was closed first by the firewall, not the Lync Server.

    If your firewall offers a reporting feature (via webinterface, or SNMP, etc.) I recommend you to take a close look to check if the connection is closed here first.

    Thanks and greetings from Berlin,
    Jan


     


    Jan Boguslawski | Technical Product Manager - snom OCS / UC Edition | MCITP: EA, MCTS OCS, MCTS EXCHANGE | snom technology AG, Berlin | www.snom.com | http://ocsphoneguy.blogspot.com
    • Marked as answer by GunniO Friday, September 9, 2011 12:02 PM
    Thursday, September 8, 2011 4:22 PM
  • Dear Jan,

    after trying with every policy used for lync on the firewall we forgot to check the protection profile (Deep Inspection) as you suggested. Disabling the protection profile temporary solved the problem!

    Thanks a lot!

    Best Regards

    Gunni


    Who needs a signature?
    Friday, September 9, 2011 12:04 PM
  • we are having the same issue here with cisco pix, we dont have any deep inspection, if i connect the external client between the firewall and the edge everything is working fine, if I take it out to the DSL just like any normal user would do it will work for normal one to one desktop sharing but not for the group conversation, any idea what is going on here.

    Normal Conversation internal-internal desktop sharing and app sharing ok

    Normal Conversation external-internal desktop sharing and app sharing ok

    Normal Conversation external-external desktop sharing and app sharing ok

    Group Conversation internal-internal  desktop sharing and app sharing    ok

    Group Conversation external-internal desktop sharing and app sharing not ok

    Group Conversation external-external desktop sharing and app sharing not ok

     

    regards


    • Edited by a.rashdan Wednesday, September 21, 2011 5:13 PM
    Wednesday, September 21, 2011 4:53 PM
  • new development, if we start sharing the desktop or application before joining the audio, IT IS WORKING. if the audio is already running we have to disconnect the audio the sharing will work then resume the audio!!!!

    Microsoft how do you explain that?

    Regards

    Wednesday, September 21, 2011 5:58 PM
  • Gunni,

    I see your 'second' issue that was solved by the Firewall change was addressed.

    But I don't see any discussion regarding the 'first' issue you cite:

    > So basically a client connects from behind a NAT device to the external IP of the edge av interface and the internal client tries to connect to the same external ip?  Is that meant to be that way?

    Can you or anyone else address this?  I assume the INTERNAL client should connect to an inside address...whether it be on the edge internal interface or on a front end. 

    Thanks,

    mG

     

     


    Mark A. Gutowski
    Thursday, January 5, 2012 12:05 AM
  • Hello Jan,

    Your blog post about these settings was really helpful. We changed a couple of other settings too.

    unset zone "DMZ" tcp-rst
    unset flow tcp-syn-bit-check
    unset flow tcp-syn-check
    set flow tcp-rst-invalid-session
    set flow no-tcp-seq-check
    unset flow tcp-syn-check-in-tunnel
    unset alg sip enable

    With these changes our issues were solved completely.

    Kind regards,
    Lieven


    • Proposed as answer by Lieven_M Friday, June 22, 2012 9:12 AM
    • Edited by Lieven_M Friday, June 22, 2012 11:23 AM
    Friday, June 22, 2012 9:12 AM
  • Hi guys, we use the SSG5 at all our client sites and see intermittent sharing issues.  I checked and we have both unset flow tcp-syn-check
    unset flow tcp-syn-bit-check

    but we have nothing about tcp-seq-check.  do we need to explicitly unset it?

    for the unset zone tcp-rst, would that be for our trust zone or untrust zone? (this is for the client branch office, not the server side).

    Friday, April 12, 2013 2:24 AM
  • I encountered the same thing here. Lync call worked fine but the desktop/app sharing between internal and external users failed. The strange thing is there is no firewall on customer's environment. They only use a route to do the NAT to the internet.Here is the client log I found:

    ms-client-diagnostics: 24; reason="Call failed to establish due to a media connectivity failure when both endpoints are remote";CalleeMediaDebug="application-sharing:ICEWarn=0x800029,LocalSite=10.30.0.90:18295,LocalMR=58.58.xx.xx:443,RemoteSite=192.168.37.1:5949,PortRange=1025:65000,LocalLocation=1,RemoteLocation=1,FederationType=0,NetworkName=xxxxx.,Interfaces=0x2,BaseInterface=0x2,BaseAddress=10.172.21.39:8438";LyncAppSharingDebug="SharerChannel:0x0; Memory Usage: totalUsedVirtual=926, availableVirtual=1120;StartupTime: 2014-01-21T02:53:48.871Z;

    Tuesday, January 21, 2014 3:24 AM