Eu tive os mesmos problemas / semelhantes. Depois de horas de solução de problemas, tenho as seguintes observações.
A ordem da cadeia de regras iptables (para a zona 'pública') é:
IN_public_log
IN_public_deny
IN_public_allow
O que significa que as regras de 'negar' são processadas antes das regras 'permitir' - portanto, isso é significativo para entender em que ordem as regras são correspondidas. Não sei se esse pedido pode ser alterado.
Eu me deparei com o mesmo problema em que emitir um firewalld-cmd --reload
não pareceu impactar se os pacotes SIP foram descartados ou aceitos, mas uma reinicialização resolveu isso.
No entanto, encontrei o comando firewalld-cmd --complete-reload
e parece estar funcionando melhor - embora eu ache que isso eliminará as sessões existentes. Mas pelo menos eu posso ter as regras do firewalld alteradas e não ter que reinicializar para que ele seja totalmente / corretamente aplicado.
Eu também notei que o sngrep ainda parece ser capaz de capturar e exibir a mensagem SIP mesmo que ela esteja bloqueada, mas mostrada com uma contagem de msg de 1 e não há mensagem de resposta (porque ela foi realmente bloqueada) .
UPDATE: Eu entendo sngrep (desde 0.1.0) usa libpcap - veja link . De acordo com este processo pós-libpcap, os pacotes (de entrada) antes de serem processados pelo 'firewall'. Eu assumo 'firewall', neste caso, também pode significar firewalld. Veja Será que tcpdump vê os pacotes que estão sendo descartados pelo iptables?
Nota: O CentOS 7 parece vir com a versão 0.4.4.4 do firewalld. O mais recente é o 0.6.0, mas ainda não sei atualizá-lo. Espero que as versões mais recentes possam resolver / corrigir os problemas acima.