O que faria com que o tráfego SIP fosse visto entrando em um switch, mas não saindo?

fundo

Tenho lutado para que meus telefones SIP se registrem atrás de um novo roteador e troquem em nosso novo escritório. Nosso PBX está hospedado fora do local. Eu trabalhei com nosso provedor para tentar várias abordagens diferentes. Tentamos o NAT regular para conectar-se ao seu controlador de borda de sessão compatível com NAT. Tentamos usar o siproxd (o pacote pfSense) para interceptar as solicitações de registro SIP e registrar-se em nome dos telefones. Finalmente, tentamos configurar os telefones manualmente para registrar com o daemon siproxd na minha rede local.

Durante os testes, vimos os telefones fazerem o seguinte com êxito:

Entre em contato com o servidor FTP hospedado pelo endereço IP
Faça o download da configuração do referido servidor
Executar consultas DNS para resolver o endereço IP do servidor NTP
Consulte o servidor NTP para definir o horário
Executar consultas DNS para resolver o endereço IP do (s) servidor (es) SIP

Sintomas

Depois que os telefones executam todas as tarefas de pré-registro com êxito, nunca vemos a tentativa de registro atingir a caixa pfSense ou o PBX do fornecedor. Eu habilitei o nível mais alto de depuração no siproxd do meu lado e não vi uma conexão TCP ou pacote UDP. No entanto, um simples telnet para a porta 5060 de uma estação de trabalho gerará mensagens de log esperadas. A realização de uma captura de pacotes na caixa pfSense não mostrou absolutamente nenhuma tentativa de tráfego SIP.

Que diabos?

Minha etapa final de solução de problemas que me surpreendeu completamente e me levou a fazer esta pergunta foi a seguinte. Primeiro espelhei a porta do switch na qual um telefone foi conectado à porta do switch da estação de trabalho. Eu realizei uma captura de pacotes de todo o tráfego na interface. Para minha surpresa, vi pacotes de registro SIP vindos do telefone. Aqui está um exemplo:

Captura de pacotes telefônicos

Claramente, o telefone está tentando se registrar nos PBXs (esses também são os endereços IP corretos).

Meu próximo passo foi espelhar a porta do switch que é alimentada no lado da LAN do roteador pfSense. Vi todo o tráfego FTP, NTP e DNS do telefone 172.200.22.102 saindo do comutador, mas não um rastro dos pacotes SIP. Isso é completamente desconcertante para mim! O que está causando apenas o tráfego SIP desaparecer dentro do switch?

Meio Ambiente

Hardware
- Roteador / Firewall: Netgate m1n1wall 2D2
- Switch: HP 1810G-24
- Telefones: Polycom SoundPoint IP 501
Software: pfSense 2.0-RC3

Configuração do Switch

O telefone com endereço IP 172.22.200.102 está na porta 4 deste switch, o link da LAN do roteador está na porta 22.

Configuração de VLAN

Participação na VLAN 200

Posso compartilhar mais configurações que possam ser necessárias.

pfsense sip switch

— Hobobave
fonte

Eu sei que é senso comum que os pacotes sejam direcionados para a interface LAN do roteador, mas não tomemos nada como garantido. Você poderia fazer o wireshark mostrar os endereços MAC de destino nos pacotes que saem do telefone e confirmar se eles são de fato o endereço MAC do roteador? Se por algum motivo eles não estivessem, isso explicaria por que você não os estava vendo na porta do espelho.

— MadHatter 22/08

@Mad: confirmou destino adequado endereço MAC do roteador

— hobodave

Droga. Valeu a pena conferir. Desculpe por não ter nenhuma idéia melhor.

— MadHatter

Encontrei a solução depois de passar aproximadamente 40 horas nesse problema.

Há uma configuração no comutador que ativa a proteção "Auto DoS". Aparentemente, considera o tráfego TCP ou UDP que possui portas de origem ou destino correspondentes um ataque flagrante e descarta o pacote. Isso é ridiculamente míope, pois o tráfego SIP geralmente (sempre?) Depende de portas de origem e destino 5060.

Caso uma descrição textual seja insuficiente:

insira a descrição da imagem aqui

— Hobobave
fonte

uau, isso é brutal. Bom trabalho encontrando isso. Aposto que também não aparece nos logs, certo?

— Gravyface

@ gravyface: correto, nada registrado. Todos os registros mostram é o elo básico cima / baixo e tentativas de autenticação

— hobodave

Whaaaaaaaaaaaaaaaat? Bom trabalho HP!

— voretaq7

Isso é péssimo; estragaria (por exemplo) o NTP e o DNS servidor-servidor também. Nas palavras de voretaq, "bom trabalho. HP". Bem diagnosticado, porém, hobodave; você merece uma cerveja!

— MadHatter

+1 - Encontrei isso hoje com a mesma opção em um aplicativo diferente. O protocolo SonicWALL "Logon único" usa datagramas UDP com as mesmas portas de origem / destino. Eu gostaria de ter olhado aqui antes de rastreá-lo com uma torneira Ethernet. É interessante notar que os quadros "ofensivos" são removidos mesmo ao espelhar a porta de entrada. Falha completa, HP. Posso confirmar que o firmware do PK 1.15, lançado em janeiro, ainda possui esse defeito.

— Evan Anderson