Estou tendo um problema com o Skype for Business (Lync) desconectando-se atrás de um firewall do pfSense após exatamente 5 segundos. É um problema estranho, e eu abri uma passagem com a Microsoft, mas até agora isso se mostrou infrutífero. Aqui está a informação:
Declaração do problema:
- Se uma chamada do Lync originar-se de dentro de nosso escritório, para um usuário VPN remoto, a chamada será conectada ao áudio bidirecional, mas será desconectada após exatamente cinco segundos com um "erro de rede". Se o usuário remoto chamar o usuário do escritório, sem problemas.
- Se um usuário do escritório tentar apresentar / compartilhar sua área de trabalho, a apresentação será iniciada e, em seguida, será interrompida após exatamente cinco segundos com um "erro de rede". Novamente, os usuários remotos podem compartilhar com usuários do escritório sem problemas.
Informação relevante:
- Esta é uma implantação do Office365 baseada em nuvem. Não há servidor no local.
- Anteriormente, tínhamos um firewall Fortigate. O Lync funcionou bem.
- Nossos usuários remotos se conectam usando o OpenVPN em execução em uma caixa pfSense atrás do gateway.
- A divisão de túnel é ativada, portanto, todo o tráfego da Internet do usuário remoto deve ir diretamente para a Internet.
- Nenhum SIP ALG está, ou já foi, habilitado em qualquer firewall.
- Nosso ISP mudou nosso espaço de endereço IP público. Na mesma época, substituímos o Fortigate por um UniFi USG Pro e funcionou por alguns meses.
- Sem alterações (óbvias) na configuração, nossos usuários remotos (conectados via VPN) começam a ter problemas.
- Por razões não relacionadas a esse problema, decidimos que o UniFi não era flexível o suficiente para as nossas necessidades. Instalamos um servidor pfSense como nosso principal dispositivo de gateway.
- Agora, os usuários da VPN se conectam diretamente ao gateway, em vez de um servidor dentro da rede.
- Com essa configuração, tudo funciona bem por algumas semanas . Achamos que o problema deve ter sido relacionado à UniFi.
- Em seguida, sem nenhuma alteração de configuração, o problema reaparece e existe agora.
Coisas que eu tentei:
- Alterando o intervalo de endereços IP internos para usuários de VPN - sem impacto.
- Configure um servidor VPN em uma interface WAN diferente (e ISP diferente) e faça com que um usuário se conecte a ele - sem impacto.
- Testado STUN / TURN de uma estação de trabalho interna para 52.112.0.75. (Servidor Lync TURN) - com sucesso
- Testado STUN / TURN de uma estação de trabalho conectada à VPN para 52.112.0.75. (Servidor Lync TURN) - com sucesso
- Defina o firewall para permitir todo o tráfego de saída da rede do Office - Sem impacto.
- Defina o firewall para permitir todo o tráfego da interface da VPN - sem impacto.
- Defina o firewall para bloquear e registrar o tráfego do STUN entre a rede corporativa e a rede VPN - sem impacto.
Esse problema ocorre 100% do tempo e é facilmente reproduzível. Reuni capturas de rede de ambos os lados da chamada e enviei logs de diagnóstico para a Microsoft. Eles me deram uma lista enorme de endereços IP para colocar na minha lista de permissões, mas não estou bloqueando nenhum tráfego de saída no momento. Eles também mostraram uma mensagem de log de uma solicitação de STUN para 52.112.0.75 falhar com uma mensagem "401 (não autorizada)", no entanto, essa falha é seguida por uma ligação de STUN bem sucedida para o mesmo endereço, então eu acho que é um arenque vermelho. Também usei um script do PowerShell para testar o STUN no computador em ambos os lados e as duas solicitações foram bem-sucedidas. Além disso, esse erro ocorre 3,5 segundos na chamada e a consulta bem-sucedida chega alguns milissegundos mais tarde. Eu acho que isso é um fracasso esperado.
Por volta da hora em que a chamada falha, vejo alguns pacotes TCP com o sinalizador RST definido, vindo do mesmo bloco de IP que o outro tráfego relacionado ao Lync. (52.112.0.0/16) Também nessa época, vejo o tráfego vindo diretamente do endereço IP do usuário remoto. Especificamente, o tráfego UDP com uma porta de destino de 3478, que é STUN.
Teorias:
Cada cliente se conecta diretamente ao servidor do Lync na nuvem. Após alguns segundos, esse servidor tenta negociar uma conexão SIP direta entre os dois clientes (por exemplo, o tráfego STUN.) E falha. A conexão direta através de uma VPN não é especificamente recomendada pela Microsoft, então eu nem sei por que ela está tentando fazer isso, e eu a impediria se soubesse como.
Este problema tem me matado por semanas, e qualquer contribuição seria muito apreciada.