Please read requirements before responding:

1) External Lync Client is attempting VIDEO or DESKTOP SHARING with Internal Lync Client via Edge access (I am aware that IM and presence work great).

2) There is no VPN established

3) The external client is on A PRIVATE NETWORK with A PRIVATE IP and BEHIND A NAT Router.

If you have gotten this to work please respond.

• Edited by Korena Monday, January 02, 2012 12:24 AM

Yes I do.  This is a typical requirement and nothing special about the setup.  Can you explain your Edge infrastructure? 

• Single/multi edge server
• NATing external NIC?
• Using single or multiple IP on external interface
• Are your two Edge interfaces on different subnets?

 

Yes, this is pretty standard. Most remote users will be behind some kind of NAT. It works fine.

Tom

Hello Korena,

Yes here too :).

Lync is ready for both; point to point and multipoint communications. for the first type (point to piont), Lync is ready - by design - for the four scenarios;

1. UDP direct: A connectivity check on the UDP ports of each user’s computer IP addresses, testing direct connectivity.
2. UDP NAT: Applies only to two users who are outside the corporate firewall that connects to the Lync infrastructure through the Edge Server. This scenario involves trying connectivity through the reflexive IP addresses for each home user. The reflexive IP Address is the public IP address of the home router.
3. UDP relay: Between two external users, or an external user and an internal user. This connectivity would be relayed through the public IP address of the Audio/Video Edge service.
4. TCP relay: The relay address (Audio/Video Edge public interface) if connectivity isn’t available on UDP, TCP Relay would be a last resort.

It is important to configure your Edge server correctly (Certificate, Firewall Ports and DNS) in order to get it work fine. What exactly is going there?

 

Edge is working great for all external access:

Our external client ----> to internal client works great even when external client is behind a NAT device (for IM and Presence)

Our external clients -----> to internal client does NOT work once client initiates video or desktop sharing if external is behind NAT device

THE KICKER!  Our external clients -----> to internal client works great for video or desktop sharing if you take the external client and plug them directly into their ISP.  In other words, No NAT for external client, they use public IP.  That is the only way it works.

Obviously our edge works great, everyone always proposes that first.  THis problem is repeatable only undert the following exact circumstances:  External client is not using VPN, is behind a NAT device with a private IP, uses video or desktop sharing with internal client.

If you are saying you have this functioning currently, could you please be very specific about the Router/NAT device and settings at the External clients location.  We have tested Linksys and Belkin with no luck.  Again, when we bypass the router/NAT at the external client side - ALL works great.  I have done extensive testing regarding this so please reply with details about External client situation.

Single Edge (configured properly for NATing external Nic) with each interface on separate subnet.

Using Single IP (multiple ports) for external interface

Consolidated Standard install on Front End

Edge is working great for all external access described below:

Our external client ----> to internal client works great even when external client is behind a NAT device (for IM and Presence)

Our external clients -----> to internal client does NOT work once client initiates video or desktop sharing if external is behind NAT device

THE KICKER! Our external clients -----> to internal client works great for video or desktop sharing IF you take the external client and plug them directly into their ISP (for testing purposes only). In other words, No NAT for external client, they use public IP. That is the only way it works.

Obviously our edge works great, everyone always proposes that first. THis problem is repeatable only undert the following exact circumstances: External client is not using VPN, is behind a NAT device with a private IP, uses video or desktop sharing with internal client.

If you are saying you have this exact functionality currently, could you please be very specific about the Router/NAT device and settings at the External clients location. We have tested Linksys and Belkin with no luck. Again, when we bypass the router/NAT at the external client side - ALL works great. I have done extensive testing regarding this so please reply with details about External client situation.

LASTLY, please confirm...

Your clients are not establishing VPN prior

Your clients are having SUCCESSFUL VIDEO from External Lync to Internal Lync, with the External Client traffic NATing at their end.

This does not apply to External to External.

Again, this should work without issue, without a VPN.  This is a typical scenario and the scenario I personally work in everyday.  Please do the following:

1. Can you make sure that logging in enable in your Lync client (Options - General - check box "Turn on logging in Lync".
2. Restart your client and attempt a audio/video call (reproduce your failure)
3. Close the client and navigate in Windows Explorer to your User profile directory and look in the Tracing folder
4. Open the Communicator*.uccapilog file in the snooper tool (part of Lync resource kit)

Post the errors related to the call setup.  If you need help with this part let me know.

Will reply with results in the next two days, I really appreciate your feedback.

Hi,Korena,

I have seen the similar desktop sharing and Audio/Video issue bettween internal and external users,and the traffic showed the Edge server trying to connect to the PRIVATE IP of the external users.It's probably you have entered the wrong public IP address in your topology builder.Please verify that your edge server config in topology builder has the public IP address of your AV edge server listed in the box that says "NAT enabled Public IP Address used". If not please correct it and republish the topology and wait for 5~10 mins for the Edge server receiving the changes.

Hope this does the trick.

Regards

 

Hi Korena,

Additionally, can you tel how do internal users access internet? (default gateway, proxy or not accessing).

If not accessing or Using Proxy, then Internal and external users will communicate using MRAS service (Edge relay) and media stream will flow as "External Client --> AV Edge --> Internal Client"

On the other hand, if Internal users connects to internet using default gateway, please confirm if there are firewall of port restrictions on the external user NAT device for outbound STUN/UDP/3478 and outbound STUN/TCP/443.

Both cases, you have to consider what pretty Sharon Shen mentioned.

Ref# Lync Server 2010 Resource Kit

Thank you,

That setting is correct - that was the first thing I verified.  Remember, everything works (including video conferencing) if the External Client is using no home router and plugged directly into their cable modem with a public IP.  This problem only occurs when the External Client is using NAT and Private IP (which of course is the norm, unless you are testing).

If a traffic trap is done with WireShark at either end the the conversation fails the second STUN/TURN/UDP begins for video. 

And you are correct, the Edge does attempt to connect to the PRIVATE IP of the client!

Users connect to internet through firewall, AD DNS forwards to ISP DNS. 

Interesting!

Please, follow Tim's advice and enable Lync logging at both ends, close and reopen the Lync client and simulate the case then using Snooper from Lync Resorce Kit, open the file "Communicator-uccapi-0.uccapilog" located in "C:\Users\<user's profile>\Tracing".

On Message tab, search for "icewarn=0x" and send me the rest of the code (i.e. 0x000, 0x003, etc.).

 

 

 

Korena,

I currently have the same symptoms.  I have not tried taking my external client and giving them a static, non-NATTed public IP.

In my failure mode, the the issue only happens when the INTERNAL CLIENT attempts to share desktop (haven't tried video) with the REMOTE CLIENT.  The reverse works fine.  The session will attempt connection and the remote user sees a 'black screen' for about 10 seconds before an error message is displayed, "network problems".

When I look at my second INVITE in the internal client traces I see that BOTH users candidate pair info is pointing at my PUBLIC EDGE interface.  Which won't work, because I don't allow generic client access on my internal network to 443/3478. 

I'm working with MSFT as well so I'll keep you updated with what I see on this end.

 

mG

 

 

hanyforever@hotmail.com

 

Problem Resolved! Thanks so much to Hany Taha and TWHarrington for offering to evaluate my log files. Nice to have someone looking from a different point of view. TWHarrington's reccomendation to turn on detailed logging and use the snooper tool in ResKit to view log files was as follows:

1.     Restart your client and attempt a audio/video call (reproduce your failure)

2.     Close the client and navigate in Windows Explorer to your User profile directory and look in the Tracing folder

3.     Open the Communicator*.uccapilog file in the snooper tool (part of Lync resource kit) - TWHarrington

Hany then had me zoom into the message where the following was located:

On Message tab, search for "icewarn=0x" and send me the rest of the code (i.e. 0x000, 0x003, etc.). - Hany Taha

The reason for having me do so was to figure out if the following could be my issue:

if Internal users connects to internet using default gateway, please confirm if there are firewall of port restrictions on the external user NAT device for outbound STUN/UDP/3478 and outbound STUN/TCP/443. - Hany Taha

I went on site and sat down with the firewall admin to evaluate every layer of security (there are many) and located and incorrect port forwarding rule for 443 somewhere along the way (port 3478 was correct). In my case this was in the inbound direction.

Lesson Learned. A client at home behind a NAT device is highly dependent on the STUN/UDP/TURN process which in turn is highly dependent on port 443.

ALL IS WORKING GREAT!!!

Still unclear: Why it was working when the client at home did not use a router and plugged straight into the Internet with public IP (I imagine they are not as dependent on the STUN/TURN process when that is the situation).

Hi Korena,

I am new in Lync, Can you please explain if I can use only Lync 2013 server itself for audio video calling for external users without having edge server?. if yes then how.

Is edge server we use for exchange 2010 are same for Lync 2013 ?

Thanks

It is recommended to deploy a Lync Edge server and reverse proxy for external access to Lync: http://technet.microsoft.com/en-us/library/gg399048.aspx. The edge server is not the same server used in Exchange 2010. 

• Proposed as answer by Gurdeep Singh Johal Tuesday, May 28, 2013 4:49 PM
• Unproposed as answer by Gurdeep Singh Johal Tuesday, May 28, 2013 4:49 PM
• Proposed as answer by Gurdeep Singh Johal Tuesday, May 28, 2013 4:49 PM

Thanks Michael! I really appreciated for the help.

Hi Team,

We have an issue in our setup.

We are from the firewall admin team and in close sync with the Exchange team to fix the issue.

Below is a summary of the issue:

1.
We are trying to initiate desktop sharing from Public internet to a user within our corporate setup.

2.
The observation is that the desktop sharing fails with an error "Sharing failed due to network issues, please try later".
The communication right now is between the external server (IP: A.B.C.D,Private IP:192.168.4.x) to the Lync server in the DMZ range (Public IP: E.F.G.H,Private IP 172.31.32.X)

3.
The firewall logs suggest that the return traffic from the edge server 172.31.32.x was hitting the private IP 192.168.4.x of the external server which should not be the case since the communication should happen with its public IP(A.B.C.D).
Please note 192.168.x.x is our internal zone subnet of our corporate setup.


We referred the below link:
http://social.technet.microsoft.com/Forums/lync/en-US/898d047b-0771-4360-bdef-aebbd3845ac1/has-anyone-successfully-had-a-video-session-or-desktop-sharing-work-with-an-external-lync-client?forum=ocsconferencing

It states the dependency of the same on STUN/TURN process.

Could someone please help us out here????

@Korena:

The below post was great but we fail to understand the return traffic hitting the private IP.

Is there any link that explains the STUN/TURN process in simple words if the issue is related to it in the first place?