none
External users cannot call internal user on lync 2013 RRS feed

  • Question

  • In my environment, I have an FE and an Edge server with 3 public IPs  all behind a firewall.  No internal firewall and all windows firewall on the servers have been disabled (FE and EDGE).

    A/V Calls, desktop sharing works internally, and also works when both users are external. But A/V calls drop and desktop sharing dont work when one user is external and the other user is internal and the clients shows network issues.Only IM and presence works between internal and external user.Below is my firewall rule

    External Firewall Rules

    Note: The following Private IPs will be Natted to their respective Public IP

    192.168.40.90 (Access edge) (Private IP)  Natted to 41.8X.8X.26 (Public IP)

    192.168.40.91 (Webconf) (Private IP)  Natted to 41.8X.8X.30 (Public IP)

    192.168.40.92 (A/V)  Natted to  41.8X.8X.31 (Public IP)

    Server  Role

    Source  IP

    Source  Port

    Protocol

    Destination

    Port

    Destination  IPs

    Communication  Type

    Direction

    Access Edge

    Any

    Any

    TCP

    443

    192.168.40.90

    External client SIP signaling

    Inbound

    Access Edge

    192.168.40.90

    Any

    TCP

    443

    Any

    Skype Consumer Directory Search

    Outbound

    Access Edge

    Any

    Any

    TCP

    5061

    192.168.40.90

    Federation SIP signaling

    Inbound

    Access Edge

    192.168.40.90

    Any

    TCP

    5061

    Any

    Federation SIP signaling

    Outbound

    Access Edge

    Any

    Any

    TCP

    5269

    192.168.40.90

    XMPP Proxy service

    Inbound

    Access Edge

    192.168.40.90

    Any

    TCP

    5269

    Any

    XMPP Proxy service

    Outbound

    Windows OS

    192.168.40.90

    Any

    TCP

    53

    Any

    Queries to external DNS servers

    Outbound

    Windows OS

    192.168.40.90

    Any

    TCP

    80

    Any

    Certificate validation and revocation checking (CRL)

    Outbound

    Web Conf Edge

    Any

    Any

    TCP

    443

    192.168.40.91

    External client/server Web Conferencing data

    Inbound

    A/V Edge

    Any

    Any

    UDP

    3478

    192.168.40.92

    External client/server media

    Inbound

    A/V Edge

    192.168.40.92

    Any

    UDP

    3478

    Any

    External client/server media

    Outbound

    A/V Edge

    Any

    Any

    TCP

    443

    192.168.40.92

    External client/server media

    Inbound

    A/V Edge

    192.168.40.92

    Any

    TCP

    443

    Any

    External client/server media

    Outbound

    A/V Edge

    Any

    Any

    TCP

    50000-59999

    192.168.40.92

    External client/server media

    Inbound

    A/V Edge

    192.168.40.92

    Any

    TCP

    50000-59999

    Any

    External client/server media

    Outbound

    is there any rule missing?

    and secondly i got this log from snooper from both clients (call between Internal  and external users)

    External User's Log

    09/30/2016|18:20:25.715 2C58:49FC INFO  :: Data Received -41.8X.8X.26:443 (To Local Address: 192.168.1.108:52375) 960 bytes:
    09/30/2016|18:20:25.715 2C58:49FC INFO  :: 
    ACK sip:129.56.0.163:37552;transport=tls;ms-opaque=e40c95a26b;ms-received-cid=6400;grid SIP/2.0
    ms-user-logon-data: RemoteUser
    Via: SIP/2.0/TLS 192.168.40.90:443;branch=z9hG4bKE6DCD55F.0E30E768C6C5B4C9;branched=FALSE
    Via: SIP/2.0/TLS 192.168.40.42:63507;branch=z9hG4bKA63297F7.51E14952A16344C7;branched=FALSE;ms-received-port=63507;ms-received-cid=6100
    Via: SIP/2.0/TLS 192.168.70.50:55371;ms-received-port=55371;ms-received-cid=AAA400
    Max-Forwards: 68
    Authentication-Info: TLS-DSK qop="auth", opaque="E9138099", srand="D005E544", snum="48", rspauth="bcfeaab15b87cddbdbc82426012ab2124c3cb8e1", targetname="lync01.domain.local", realm="SIP Communications Service", version=4
    From: <sip:test2@domain.com>;tag=9305ca3beb;epid=9f9be453fc
    To: <sip:test1@domain.com>;epid=25ded2ff45;tag=c68df9b444
    Call-ID: e0fefb8288d94401abf8b9052c9de5ce
    CSeq: 1 ACK
    User-Agent: UCCAPI/15.0.4420.1017 OC/15.0.4420.1017 (Microsoft Lync)
    Content-Length: 0

    09/30/2016|18:20:25.716 2C58:49FC INFO  :: End of Data Received -41.8X.8X.26:443 (To Local Address: 192.168.1.108:52375) 960 bytes




    09/30/2016|18:20:34.835 2C58:49FC INFO  :: Data Received -41.8X.8X.26:443 (To Local Address: 192.168.1.108:52375) 1469 bytes:
    09/30/2016|18:20:34.835 2C58:49FC INFO  :: 
    BYE sip:129.56.0.163:37552;transport=tls;ms-opaque=e40c95a26b;ms-received-cid=6400;grid SIP/2.0
    ms-user-logon-data: RemoteUser
    Via: SIP/2.0/TLS 192.168.40.90:443;branch=z9hG4bKF558277D.CBD29107C93E84D3;branched=FALSE;ms-internal-info="cfzq9kUCIToUOX5E-MjG9cODA4ueaEgodl_0VO80jViSAHkdLL2gRpbgAA"
    Via: SIP/2.0/TLS 192.168.40.42:63507;branch=z9hG4bKB8689621.225D2853A3DC04D1;branched=FALSE;ms-received-port=63507;ms-received-cid=6100
    Via: SIP/2.0/TLS 192.168.70.50:55371;ms-received-port=55371;ms-received-cid=AAA400
    Max-Forwards: 68
    Authentication-Info: TLS-DSK qop="auth", opaque="E9138099", srand="16D180E1", snum="49", rspauth="92722824ed8fe9a9ec3810bd1c3947e975e9541b", targetname="lync01.domain.local", realm="SIP Communications Service", version=4
    From: <sip:test2@domain.com>;tag=9305ca3beb;epid=9f9be453fc
    To: <sip:test1@domain.com>;epid=25ded2ff45;tag=c68df9b444
    Call-ID: e0fefb8288d94401abf8b9052c9de5ce
    CSeq: 3 BYE
    User-Agent: UCCAPI/15.0.4420.1017 OC/15.0.4420.1017 (Microsoft Lync)
    ms-client-diagnostics: 23; reason="Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote";CalleeMediaDebug="audio:ICEWarn=0x2b,LocalSite=192.168.70.50:8116,LocalMR=192.168.40.70:3478,RemoteSite=192.168.41.1:29898,PortRange=1025:65000,LocalLocation=2,RemoteLocation=1,FederationType=0,NetworkName=domain.local,Interfaces=2,BaseInterface=2,BaseAddress=192.168.70.50:31076"
    Content-Length: 0

    09/30/2016|18:20:34.835 2C58:49FC INFO  :: End of Data Received -41.8X.8X.26:443 (To Local Address: 192.168.1.108:52375) 1469 bytes



    09/30/2016|18:20:34.836 2C58:49FC INFO  :: Sending Packet - 41.8X.8X.26:443 (From Local Address: 192.168.1.108:52375) 917 bytes:
    09/30/2016|18:20:34.836 2C58:49FC INFO  :: 
    SIP/2.0 200 OK
    Via: SIP/2.0/TLS 192.168.40.90:443;branch=z9hG4bKF558277D.CBD29107C93E84D3;branched=FALSE;ms-internal-info="cfzq9kUCIToUOX5E-MjG9cODA4ueaEgodl_0VO80jViSAHkdLL2gRpbgAA"
    Via: SIP/2.0/TLS 192.168.40.42:63507;branch=z9hG4bKB8689621.225D2853A3DC04D1;branched=FALSE;ms-received-port=63507;ms-received-cid=6100
    Via: SIP/2.0/TLS 192.168.70.50:55371;ms-received-port=55371;ms-received-cid=AAA400
    From: "test2"<sip:test2@domain.com>;tag=9305ca3beb;epid=9f9be453fc
    To: <sip:test1@domain.com>;epid=25ded2ff45;tag=c68df9b444
    Call-ID: e0fefb8288d94401abf8b9052c9de5ce
    CSeq: 3 BYE
    User-Agent: UCCAPI/15.0.4859.1000 OC/15.0.4859.1000 (Skype for Business)
    Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="E9138099", targetname="lync01.domain.local", crand="07ec0423", cnum="46", response="49c80d3671c1cff40f1f831faeb285e686d2af21"
    Content-Length: 0

    09/30/2016|18:20:34.836 2C58:49FC INFO  :: End of Sending Packet - 41.8X.8X.26:443 (From Local Address: 192.168.1.108:52375) 917 bytes



    INTernal User's Log

    09/30/2016|18:20:23.642 4758:4998 INFO  :: Sending Packet - 192.168.40.42:5061 (From Local Address: 192.168.70.50:55371) 790 bytes:
    09/30/2016|18:20:23.642 4758:4998 INFO  :: 
    ACK sip:test1@domain.com;opaque=user:epid:hNpNubCth1GmdKE6rdv-GwAA;gruu SIP/2.0
    Via: SIP/2.0/TLS 192.168.70.50:55371
    Max-Forwards: 70
    From: <sip:test2@domain.com>;tag=9305ca3beb;epid=9f9be453fc
    To: <sip:test1@domain.com>;epid=25ded2ff45;tag=c68df9b444
    Call-ID: e0fefb8288d94401abf8b9052c9de5ce
    CSeq: 1 ACK
    Route: <sip:lync01.domain.local:5061;transport=tls;opaque=state:T:F:Eu:Ci.Raaa400;lr;ms-route-sig=ad2kiY4VSYNFuk9l8LDU0aR2y7ENjrMRVWBCMRzOHmWwRHo2Pada6ELAAA>
    User-Agent: UCCAPI/15.0.4420.1017 OC/15.0.4420.1017 (Microsoft Lync)
    Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="807E4A65", targetname="lync01.domain.local", crand="39de2c35", cnum="142", response="93572dd21c208476f9673ee535c7bd6ffca43f5d"
    Content-Length: 0

    09/30/2016|18:20:23.642 4758:4998 INFO  :: End of Sending Packet - 192.168.40.42:5061 (From Local Address: 192.168.70.50:55371) 790 bytes





    09/30/2016|18:20:33.766 4758:4998 INFO  :: Sending Packet - 192.168.40.42:5061 (From Local Address: 192.168.70.50:55371) 1221 bytes:
    09/30/2016|18:20:33.766 4758:4998 INFO  :: 
    BYE sip:test1@domain.com;opaque=user:epid:hNpNubCth1GmdKE6rdv-GwAA;gruu SIP/2.0
    Via: SIP/2.0/TLS 192.168.70.50:55371
    Max-Forwards: 70
    From: <sip:test2@domain.com>;tag=9305ca3beb;epid=9f9be453fc
    To: <sip:test1@domain.com>;epid=25ded2ff45;tag=c68df9b444
    Call-ID: e0fefb8288d94401abf8b9052c9de5ce
    CSeq: 3 BYE
    Route: <sip:lync01.domain.local:5061;transport=tls;opaque=state:T:F:Eu:Ci.Raaa400;lr;ms-route-sig=ad2kiY4VSYNFuk9l8LDU0aR2y7ENjrMRVWBCMRzOHmWwRHo2Pada6ELAAA>
    User-Agent: UCCAPI/15.0.4420.1017 OC/15.0.4420.1017 (Microsoft Lync)
    ms-client-diagnostics: 23; reason="Call failed to establish due to a media connectivity failure when one endpoint is internal and the other is remote";CalleeMediaDebug="audio:ICEWarn=0x2b,LocalSite=192.168.70.50:8116,LocalMR=192.168.40.70:3478,RemoteSite=192.168.41.1:29898,PortRange=1025:65000,LocalLocation=2,RemoteLocation=1,FederationType=0,NetworkName=domain.local,Interfaces=2,BaseInterface=2,BaseAddress=192.168.70.50:31076"
    Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="807E4A65", targetname="lync01.domain.local", crand="9a71a5b4", cnum="143", response="166098d34e8568f096ea809062686a0ade37954b"
    Content-Length: 0

    09/30/2016|18:20:33.766 4758:4998 INFO  :: End of Sending Packet - 192.168.40.42:5061 (From Local Address: 192.168.70.50:55371) 1221 bytes





    09/30/2016|18:20:34.036 4758:4998 INFO  :: Data Received -192.168.40.42:5061 (To Local Address: 192.168.70.50:55371) 622 bytes:
    09/30/2016|18:20:34.036 4758:4998 INFO  :: 
    SIP/2.0 200 OK
    Authentication-Info: TLS-DSK qop="auth", opaque="807E4A65", srand="146171E4", snum="196", rspauth="0f5d4a447b0ad61469de1933d19e1b5849b6014b", targetname="lync01.domain.local", realm="SIP Communications Service", version=4
    Via: SIP/2.0/TLS 192.168.70.50:55371;ms-received-port=55371;ms-received-cid=AAA400
    From: "test2"<sip:test2@domain.com>;tag=9305ca3beb;epid=9f9be453fc
    To: <sip:test1@domain.com>;epid=25ded2ff45;tag=c68df9b444
    Call-ID: e0fefb8288d94401abf8b9052c9de5ce
    CSeq: 3 BYE
    User-Agent: UCCAPI/15.0.4859.1000 OC/15.0.4859.1000 (Skype for Business)
    Content-Length: 0

    09/30/2016|18:20:34.036 4758:4998 INFO  :: End of Data Received -192.168.40.42:5061 (To Local Address: 192.168.70.50:55371) 622 bytes



    Saturday, October 1, 2016 8:31 AM

All replies

  • For Audio/Video, the external A/V Edge IP 192.168.40.92 will be used and the internal IP of the Edge server.

    You should check that the external client can reach the A/V Edge IP. The best way is to run wireshark also on both clients and on the edge to check that the correct ports are used and the call flow is going through the Edge.

    Most common problems are network or firewall misconfiguration. 


    regards Holger Technical Specialist UC

    Saturday, October 1, 2016 10:58 AM
  • the external clients can reach the a/v edge Public IP. And like i said external to external calls are connecting.What port should i be looking for on wireshark?  Thanks for your response.
    Saturday, October 1, 2016 11:43 AM
  • Hi Abdul.

    You should have a look at your Edge server configuration, I think you missed some NAT configuration in your topology.

    Why: In the ms-diagnostics field of the SDP message, you should have a MediaRelay server (LocalMR, RemoteMR), these should be the public IP of the AV edge and if user is external it can have the same value.

    Also the ICEwarn field says 0x2B, that means the client cannot establish a UDP or TCP connection to the TURN server, which is not in the SDP.

    Please post the results of the GUI topology check and Get-CsAVEdgeConfiguration cmdlet.


    Kenneth ML<br/> Please remember, if you see a post that helped you please click Vote on the left side of the response, and if it answered your question please click Mark As Answer.

    Saturday, October 1, 2016 2:04 PM
  • PS C:\> Get-CsAVEdgeConfiguration | fl


    Identity              : Global
    MaxTokenLifetime      : 08:00:00
    MaxBandwidthPerUserKb : 10000
    MaxBandwidthPerPortKb : 3000

    Cant add the Gui topology because my account is yet to be verified. i can send you an email if you want.

    sorry for the delay in response and let me know if you require additional logs.

    Plus i have no record for for Av, Sip and webconf internally only external records are available can that be an issue for internal users?

    Thanks

    Saturday, October 1, 2016 5:10 PM
  • You don't need the DNS entries internal, only the internal FQDN of the Edge. You should also be sure that the internal clients cannot reach the external IP's of the Edge.

    regards Holger Technical Specialist UC

    Saturday, October 1, 2016 7:45 PM
  • Hi Abdul.

    Don't send me an e-mail, put info in this thread, so others can see and learn from it as well, sharing is caring :-)

    I am pretty certain your problem is in the Edge server topology builder public NAT IP. Please post the setup when you can.


    Kenneth ML || Please remember, if you see a post that helped you please click Vote on the left side of the response, and if it answered your question please click Mark As Answer.

    Saturday, October 1, 2016 8:25 PM
  • ok thanks.
    Sunday, October 2, 2016 11:35 AM
  • Alright Thanks. I hope my acct can be verified before tomorrow so that i can post a screenshot of my topology.
    Sunday, October 2, 2016 11:36 AM
  • first thing to do please run netmon on the Edge box: 

    you should be able to see MRAS request check if a successful reply exist (there is a failure for first one expected)

    next you should see clients trying to communicate with candidate provided by the other client. check if there is any failure... 

    Please note that 50k port doesn't  need to be opened as destination 

    client always use 3478 or fall back to 443 during screen sharing they use only 443 (source port is 50K)


    Sunday, October 2, 2016 8:36 PM
  • Hi

    That is the edge server config. Plus the two interfaces on the edge server are both on the same subnet. I know this is not the best practise but can that be an issue?

    thanks

    Tuesday, October 4, 2016 11:20 AM
  • If both interfaces on the same subnet, how do you have configured your routing?

    I could work, if the manual route is configured correct for both nic interfaces, but still not supported.

    It is important to route the internal traffic different from the external traffic to be sure that internal traffic will always use the internal interface and also the external traffic will use the external traffic.


    regards Holger Technical Specialist UC

    Tuesday, October 4, 2016 11:28 AM
  • Thank you for your response. This is actually a POC to demonstrate how Lync can help boost productivity and that is why a DMZ was not created. The edge and the FE are all on the same subnet. so i didnt create any static route on th edge since the edge can talk to the FE and DC. Presently only IM and presence is working for Internal vs external user ( app & desktop sharing, A/V call not working). but everything works for external vs external user scenerio. Or is a route needed even in this scenerio?
    Tuesday, October 4, 2016 12:02 PM
  • Thing is, you need to make your default route use the Internet interface (192.168.40.90) and a route for all internal networks that uses the internal interface (192.168.40.70). They can use the same gateway, but you might need to fiddle a little with the network binding order, to make traffic to other hosts on 192.168.40.0/24 (assumption) network go through the internal interface.


    Kenneth ML || Please remember, if you see a post that helped you please click Vote on the left side of the response, and if it answered your question please click Mark As Answer.

    Wednesday, October 5, 2016 8:43 AM
  • Find the SIP messages where the clients share the candidates when you are establishing the call between int/ext. Double check also, that you can get MRAS cert for your clients (verify that connection to AV edge is working).

    Keep in mind also, that if your test call between ext-ext is working fine, the reason for that could be P2P call. As you might know, Lync/Skype clients prefer the shortest way for the calls. And if e.g. your external clients are on the same subnet, or they do not have connectivity restrictions then the call is most likely P2P call.

    Have you tested are they (external clients) able to join to meetings?

    And finally, ask your FW team to analyze the FW logs more deeply. Sometimes they might not log if e.g. the UDP packages are dropped.

    Btw, you told that edge and FE are on the same subnet, and perhaps DCes as well. It was still so, that your edge was not part of the same AD domain than your FEs are?


    Petri

    Wednesday, October 5, 2016 9:56 PM
  • Hi Abdul, can you verify the necessary ports that are opened correctly 443,3478 inbound and outbound both TCP and UDP. Make sure that the FE can talk to the Internal interface of the Edge server on 5062 , you can also check the MRAS from the client side by checking the Configuration information (+ shift , right click Lync icon -system tray and click configuration). This should display the MRAS information. Check for the 50k port range is open Oubound from the Edge server.

    Linus || Please mark posts as answers/helpful if it answers your question.

    Thursday, October 6, 2016 10:09 AM
  • Thank you very much guys for your responses. I think my issue is a firewall problem. I am waiting on my Firewall team to look at their config before i post anything here. I think port 3478 is not accessible. Thank you very much once again.

    will post as soon as i figure out the firewall issue with my team

    Friday, October 7, 2016 11:33 AM
  • Hi Abdul,

    was this issue resolved as i am facing same issue.

    Sunday, August 25, 2019 10:11 PM