There can be many reasons why Lync cannot contact external contacts. I have put a checklist together on the most common thing you should check to successful connect to federated partners.
Even if you are setting Lync up for the first time or you have done it several times, you might end up making a mistake in the configuration or forget something in the setup.
So use this guide to check if you have configured everything correct – which you might not have, since you are looking at this blog J
1. Topology Builder
Edit properties at the site level and make sure that federation has been enabled in the topology builder.
Select properties on the Edge Server Pool
Make sure that the port on the Access Edge service has NOT been set to 5061. It must be 443.
Make a record on the three names that have been defined – you will check them later on.
2. Lync Control Panel
Navigate to “Federation and External Access”.
Select the “External Access Policy” – Check that the users is allowed to communicate with external contacts.
If you have made several policies, make sure that the user has a policy which actually gives them access to contacts the users contacts.
Select “Access Edge Configuration” and make sure that “Enable Federation…” has been checked.
3. Public DNS
As part of the configuration of Lync a number of DNS records has been (or should have been) created in the public DNS.
You can check the record on a internet based service like http://network-tools.com/nslook/ or you can use nslookup.exe from a command prompt.
Type server 188.8.131.52
Type set type=ALL
You should now check or double check these records – and make sure that you have not made a typo and write a wrong name or ip address:
_sipfederationtls._tcp.YOUR-DOMAIN-NAME.COM – should point to your SIP record and the correct sip port (5061)
_sip._tls.YOUR-DOMAIN-NAME.COM – Should point to your sip record and the correct port (443)
Check these dns records as well (with the names you found in step 1) and check they have the correct Ip adresse (defined in the topology builder, under the each edge server):
Check the firewall, and that you have created the right port openings.
The frontend server must be able to communicate with the Edge servers internal DMZ IP address on these ports:
Frontend->Edge Server Internal DMZ IP.
- 5061/tcp (sip)
- 5062/tcp (if mediation server is collocated)
- 443/tcp (stun)
- 3478/udp (stun)
- 4443/tcp (replication)
- 8057/tcp (psom)
- 23456/tcp (if using xmpp)
- 50001-50003/tcp (for logging)
Make sure that you can have manually created an DNS record in the internal DNS, which points to the edge servers internal DMZ IP. (FQDN name)
Edge Server Internal IP -> Frontend Server and or Director
Make sure that you manually have created a route to ALL the internal network segments, so that the edge server can route traffic to the internal lync servers and also the clients.
(like this “route add 192.168.0.0 mask 255.255.255.0 172.16.1.1 if 12 -p” where if is the interface for the internal DMZ nic.
Also make sure that you either use an internal DNS server or have a host file with the names of the frontend/directors servers.
The traffic to from the edge server and the internal lan must be routed (don’t NAT that traffic)
The Edge server public nic should be able to communicate with your partners on the internet, and you can use either NAT (if you only have one edge server), or public ip addresses on the edge server if you have multiple edge servers.
These ports must be opened to and from the edge server (both directions)
- 443/tcp to the sip ip.
- 5061/tcp to the sip ip.
- 5269/tcp to the sip ip.
- 443/tcp to the webconf ip
- 443/tcp to the av ip
- 3478/stun to the av ip
If you are using NAT, then make sure that the public ip’s are pointing to the right ip addresses on the edge servers public ip’s.
I hope this check list can help you find the error which is causing you not to be able to federate.
In a later blog post I will show some advanced troubleshooting on other errors which can cause federation not to work correctly.