Hello:

We have having an issue with our Lync setup, specifically when external users are trying to make a phone call.   For example, if someone at home tries to call someone here at corporate thru Lync what is happening is:

1) Call is placed
2) Signal is getting to the phone and it rings
3) Callee tries to answer the phone and the audio is never established.

Running packet traces finds that the traffic at the point of answering is trying to go back out using the private address of the home user (ie if the users WAN address is 70.80.90.100 and their private address is 192.168.1.100) the traffic.  Obviously this doesnt work as its not routable and there is a Deny error in the Cisco confirming this.   In the Lync Edge Server setup I see the Audio/Video Edge service external FQDN and internal FQDN say not set.  Is this related?   Ive found an article that states these need to be set to "av.yourdomainname.org" for the external and the internal should be "srv-lyncedge.yourdomainname.org".   IM, desktop sharing, etc all seem to work fine.   The article also states that this is possibly a bug and should always be set to Not Set.  I have also gone into the Topology Builder and for the A/V Edge service i am seeing:

FQDN: av.yourdomain.org, NAT Enabled, IP 192.168.X.9, NAT-Enabled public IPv4 address 98.XXX.XXX.128 (which is outside of our assigned range, which starts at 98.xxx.xxx.129), Port 443, Protocol TCP.   

Thanks,

Joe

• Edited by Joseph Bucar Wednesday, April 15, 2015 3:50 PM

Anthony:

No we do not own that IP we are using.  .148 appears to be the AV External IP address and its possible the previous admin mistyped it.  We are using three public IPs. 

>> Can you resolve av.yourdomain.org from the outside?

Yes it pings from outside.

>> Can you resolve the lync edge pool name from the inside and does it point to the internal IP of the edge server?

Yes to both.

It would probably be more helpful as well to see the firewall deny message.  Ive tried to post an image but it says until my account is verified I cant.   From the Cisco Log:

172.xxx.xxx.103   53488    192.168.43.221 32436  Deny udp src inside: 172.xxx.xx.103/53488 dst outside:192.168.43.221/32436 by access-group "acl_in2out" 

Where .103 is the internal Lync Server IP and the 192 address is the actual private address of the external client.

Is some sort of NATing not happening?   

I have also now noticed on the Lync Edge server that the Lync Server Access Edge service will not start.  Every time I try to start it I get a 

The Lync Server Access Edge service terminated with service-specific error %%-1008124915.  Same for Web Conferencing Edge except the error number is %%-2147467259.

Thanks,

Joe 

• Edited by Joseph Bucar Wednesday, April 15, 2015 6:49 PM

Eason:

The external clients are using the external address to connect.  The signaling obviously works as the phone rings the problem happens when someone answers the audio doesnt look like its routing back out the public ip, it is using the private address of the external client.  Looks to be correct to me.   The certificate is below:

Thanks,

Joe

Anthony:

Below are the screen shots your requested.

Ok, so with those settings in place, and appropriate replication, you should now be able to start services.  You'll need to edit the public IP to match what you're NATing for the AV since you don't own .128.  The certificate looks OK, but you won't need a cert for av.xxx.org and you have lyncdiscover in there, which would go on your reverse proxy, but if you're using the same certificate for your reverse proxy you'd also need more SANS.

Also, for each NAT, the 98.x.x.x to 192.168.50.7 for SIP, make sure it's bi-directional.  Inbound traffic to 98. should hit 50.7 and outbound traffic initiating from 50.7 should look like that unique IP.

Run get-csmanagementstorereplicationstatus and see if replication to your Edge reports as true.

If it doesn't show True, then we'll do it manually.  From a front end run "export-csconfiguration -filename edge.zip" and copy that file to your edge.  On your edge run "import-csconfiguration -filename edge.zip -localstore".

Do all of your services start then?  If so, the next step is double checking all ports.

Anthony:

Running the get-csmanagementstorereplicationstatus command shows True.

Ive attached my firewall rules to see you feel they look ok?

Thanks,

Joe

That's good for the external access edge interface if you're not using XMPP.  However, if it's just the call we're concerned with, we'll want to see the rules for the internal interface to the internal networks, and also the rules for the AV Edge which should map to 148.

Anthony:

Can I safely change the 98.xxx.xxx.128 address to 98.xxx.xxx.148 in the setup without causing any downtime in the phone system?

Thanks,

Joe

Yes, if we're talking about the edge section of the topology builder and internal-external audio between users is broken anyway, which it should be if that's incorrectly set.

Just want to thank Anthony for all the help in getting this issue straightened out.   It turned out to be

several different things, including:

1) Bad address in the Topology Builder for the External AV Edge server

2) Issue with Certificate on the Edge Server

3) Services not starting due to the Certificate issue

4) Bad External DNS entry which was causing the external clients to appear as internally connected clients even when they were for sure external.   Removal of the entry out of the external DNS caused the proper Internal/External server names to populate.

Thanks,

Joe