none
Lync Application/Desktop sharing doesnt work in Federation RRS feed

  • Question

  • when trying to use application/desktop sharing with federated contacts the error appears in logs:

    ms-client-diagnostics: 25; reason="A federated call failed to establish due to a media connectivity failure where both endpoints are internal";

    CallerMediaDebug="application-sharing:ICEWarn=0x29,

    LocalSite=192.168.15.43:22013, LocalMR=10.19.9.3:3478,

    RemoteSite=10.64.3.5:58023, RemoteMR=96.98.126.130:52652,

    PortRange=1025:65000, RemoteMRTCPPort=52652,

    LocalLocation=2,RemoteLocation=2,FederationType=1"

    the firewall is configured to allow all traffic from federated network

    the edge config is as follows:

    SIP Access

    FQDN: sip.extaddr.com

    IP: 96.98.126.130

    Port: 5061

    Protocol: TLS

    Web Conferencing Edge Service

    FQDN: sip.extaddr.com

    IP: 96.98.126.130

    Port: 444

    Protocol: TLS

    A/V service

    FQDN: sip.extaddr.com

    IP: 96.98.126.130

    Port: 443

    Protocol: TCP


    .

    from LAN to Edge Internal interface there are no ports blocked. tcp:443/4443, upd:3478 are available for connect


    • Edited by y0sh1 Monday, July 30, 2012 10:59 AM
    Monday, July 30, 2012 10:10 AM

All replies

  • Hi,

    normal this error could happene of misconfiguration on the Firewall. Ist your Firewall configured to Support NAZ inbound and outbound?

    Check also, that the Port 5062 is reachable on the Edge.

    Check your dns Settings on the Edge, should Point to the public dns.

    Also the Default GW should be the external GW


    regards Holger Technical Specialist UC


    Monday, July 30, 2012 10:52 AM
  • Hi,

    normal this error could happene of misconfiguration on the Firewall. Ist your Firewall configured to Support NAZ inbound and outbound?

    Check also, that the Port 5062 is reachable on the Edge.

    Check your dns Settings on the Edge, should Point to the public dns.

    Also the Default GW should be the external GW


    regards Holger Technical Specialist UC


    I agree that this is a some misconfig. of Firewall but where?

    We have two FW:

    a cisco ASA that is between External edge interface and Internet and

    a Microsoft TMG that is between Internal edge inerface and Lan, and it is also a reverse-proxy for Lync

    All standard ports (50000-59999/443/4443/444) are allowed on appropiate firewalls

    Which of these two firewall should support SNAT/DNAT ? Cisco ASA is configured as SNAT/DNAT for Edge external interface and it is 100% works (all other federation features works find and there are another servers that cisco ASA natting to/from internet). Microsoft TMG is not configured as NAT for any users. should it be?

    The other checks you suggested are passed OK (dns/5062/def.gw)

    Monday, July 30, 2012 11:26 AM
  • It also could be a routing problem. Do you configured the correct routes to direct traffic to your internal subnet, via the Edge network adapter declared as internal?

    Regarding the firewall rules on the TMG:

    from LAN to Edge Internal interface there are no ports blocked. tcp:443/4443, upd:3478 are available for connect

    Did you also test SIP/MTLS 5062, PSOM/MTLS 8057 (shouldn't matter in this case, but has to be tested anyway)?What about the other way around? Port 5061 from Edge Internal interface to the Frontend Pool?

    And no, there shouldn't be any nat between your DMZ and the internal network, therefore no NAT on the TMG.

    You say:

    Cisco ASA is configured as SNAT/DNAT for Edge external interface and it is 100% works

    Did you configure the "NAT enabled public IP address used" in the Topology Builder for the Edge server to 96.98.126.130?

    Monday, July 30, 2012 3:25 PM
  • Hi

    A similar issue just for your reference:

    http://social.technet.microsoft.com/Forums/en-ZA/ocsedge/thread/61bd27ba-ae5d-4335-a2c8-17d16f10a0dd/


    Regards,

    Kent Huang

    TechNet Community Support

    ************************************************************************************************************************

    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.


    • Edited by Kent-Huang Tuesday, July 31, 2012 7:52 AM
    Tuesday, July 31, 2012 7:52 AM
  • It is not a routing probem. all routes a OK and have been checked at first time.

    .

    No any packets are blocked from LAN to Internal Edge interface. I mean there is a rule on MS TMG: "allow any protocol any port from LAN to Internal Edge". 

    .

    From internal edge to Frontend pool works fine. Tested ports: upd/3478, tcp/443,5061

    about external interface: i checked with our border admin and he says it is not natting at all:

    The thing is that the ip address is specified on Edge as-is i.e. 96.98.126.130.  And it is just out and in via ASA by default route:

    .

    -------- this is a snippet from ASA config (it is well - commented)----------------

    interface Ethernet0/2.991
     description Internet services with public ip
     vlan 991
     nameif inetsvc
     security-level 50
     ip address 96.98.126.129 255.255.255.240

    !
    ! allow connect from internet to Edge external interface on ports tcp:443,444,5061,50000-59999

    !                 udp: 3478, 50000-59999

    !

    access-list ISP2 extended permit tcp any host 96.98.126.130 eq https
    access-list ISP2 extended permit tcp any host 96.98.126.130 eq 444
    access-list ISP2 extended permit tcp any host 96.98.126.130 eq 5061
    access-list ISP2 extended permit tcp any host 96.98.126.130 range 50000 59999
    access-list ISP2 extended permit udp any host 96.98.126.130 range 50000 59999
    access-list ISP2 extended permit udp any host 96.98.126.130 eq 3478
    !

    ! do not nat the whole network 

    nat (inetsvc) 0 96.98.126.128 255.255.255.240
    !

    ! Forward all allowed connects from internet to the edge external interface

    static (inetsvc,isp2) 96.98.126.130 96.98.126.130 netmask 255.255.255.255

    --------------------------------------------------------------------

    and NAT is disabled in topology builder. 


    • Edited by y0sh1 Tuesday, July 31, 2012 10:49 AM change NAT
    Tuesday, July 31, 2012 10:17 AM
  •  I assume, by the fact you are solely referring to app sharing here, and not AV, that AV works.

     Inspect your ICE Candidate list in your client logs to ensure that you have a complete list (local IP, Relay IP and SRV RFLX IP addresses). If you're ONLY sending out local IP addresses when negotiating ICE (look at SDP for the INVITE if initiating sharing, or the 183 or 200OK if not the initiator) then your TURN requests on port 443 to the edge are likely failing.

     You stated you tested 443... I would assume via telnet or similar method... ensure via network cap at your edge server that your TURN requests on 443 are actually reaching the edge. Check this for internal clients (peer to peer) as well as your test for ASMCU: "From internal edge to Frontend pool works fine. Tested ports: upd/3478, tcp/443,5061"

    Tuesday, July 31, 2012 10:28 PM
  • yes, we have no problems with A/V - it works just fine in both directions.

    .

    The ICE candidates are  my computer's IP (10.64.3.5) and the Edge IP:


    a=candidate:1 1 TCP-PASS 2120613887 10.64.3.5 58084 typ host
    a=candidate:1 2 TCP-PASS 2120613374 10.64.3.5 58084 typ host
    a=candidate:2 1 TCP-ACT 2121006591 10.64.3.5 58005 typ host
    a=candidate:2 2 TCP-ACT 2121006078 10.64.3.5 58005 typ host
    a=candidate:3 1 TCP-PASS 6556159 96.98.126.130 51677 typ relay raddr 10.64.3.5 rport 58030
    a=candidate:3 2 TCP-PASS 6556158 96.98.126.130 51677 typ relay raddr 10.64.3.5 rport 58030
    a=candidate:4 1 TCP-ACT 7076607 96.98.126.130 51677 typ relay raddr 10.64.3.5 rport 58030
    a=candidate:4 2 TCP-ACT 7076094 96.98.126.130 51677 typ relay raddr 10.64.3.5 rport 58030

    .

    The more interesting - an other side responses with it's candidates limited to only he's local IP:

    a=candidate:1 1 TCP-PASS 2120613887 192.168.15.15 31568 typ host
    a=candidate:1 2 TCP-PASS 2120613374 192.168.15.15 31568 typ host
    a=candidate:2 1 TCP-ACT 2121006591 192.168.15.15 16361 typ host
    a=candidate:2 2 TCP-ACT 2121006078 192.168.15.15 16361 typ host

    .

    as you can see - there is no Edge server on the opponent's side. Why? where should they configure it?

    .

    There were a TURN requests (from Edge) that tried to go on port  UDP 3478 (not tcp/443), but they tried to go to the only ONE federated side's internal interface (192.168.15.15). Only on this IP. of couse they never reached it.  There were NO other STUN packets on cap. The whole cap filtered by "udp.port = 3478" looks like this:

    SRC:96.98.126.130 DST:192.168.15.15 PROTO:STUN

    SRC:96.98.126.130 DST:192.168.15.15 PROTO:STUN

    SRC:96.98.126.130 DST:192.168.15.15 PROTO:STUN

    SRC:96.98.126.130 DST:192.168.15.15 PROTO:STUN

    SRC:96.98.126.130 DST:192.168.15.15 PROTO:STUN

    .

    and no other STUN packets

    .

    .

    I must say that the application sharing works fine when one internal client is on the DMZ network and other on LAN (no federation) just to sure the STUN is working and the TURN requests are go on edge.

    by 'internal' i mean both users are in the same domain on the same Lync FE pool








    • Edited by y0sh1 Wednesday, August 1, 2012 7:50 AM
    Wednesday, August 1, 2012 3:55 AM
  • analizing the Communicator-uccapi-0.uccapilog i found the ICEWarn error codes that comes from a federated client side:

    0x9 and 0x220

    I think it means that it is a firewall misconfiguration on their side. I asked them to recheck the availablility of udp/3478 and tcp/443 ports from client pc to internal edge interface....hope it is the root of the problem

    Thursday, August 2, 2012 10:09 AM
  • Sounds like you're on the right track.. you will never talk to them if they cannot negotiate a relay address/port. Specifically for sharing they will need to dig into port 443 TURN requests...
    Thursday, August 2, 2012 5:45 PM