A resposta ARP desaparece de br0 para tap0 usando o OpenVPN no modo de ponte

Question

Eu configurei uma caixa linux (em um esxi5) que funciona como um servidor OpenVPN. o servidor está configurado para usar bridging para os clientes, o que essencialmente funciona, com uma exceção.

Se o cliente pings alguma máquina na rede que não é o próprio servidor, não funciona. Eu descartei tudo o que eu sabia (iptables, etc) e rodando o tcpdump resumia as seguintes coisas:

• vejo solicitações de ARP em tap0 e br0
• vejo as respostas do ARP em br0
• NÃO vejo as respostas do ARP em tap0

Pergunta: por que o dispositivo br0 não encaminha o ARP responde ao dispositivo tap0?

    

Answer 1

Sem mais informações, estamos adivinhando, mas vamos tentar:

Primeiro, certifique-se de que eth0 e tap0 estejam no modo promíscuo. br0 não deve estar no modo promíscuo.

Em seguida, verifique se você tem arutables e quaisquer regras iptables que possam estar interferindo.

Como você já recebeu respostas do arp, você provavelmente não tem este , mas verifique-o assim mesmo.

finalmente verifique as configurações de rp_filter , mas também verifique os parâmetros adicionais de sysctl que você possa ter definido.

    

Answer 2

Se o seu host ESXi tiver conexões redundantes com a rede, há uma variedade de problemas de ARP que podem aparecer devido à configuração padrão de Net.ReversePathFwdCheckPromisc. Os usuários do pfSense usando o CARP estavam entre os primeiros a depurar isso, descritos no link

Em um ambiente similar, temos a ponte OpenVPN configurada no FreeBSD, mas também a complicação adicional das vlans. Em um host em que Net.ReversePathFwdCheckPromisc não foi definido como 1 e em que há vários uplinks para a rede, vemos uma perda massiva de pacotes (95% +) no tráfego de entrada para o dispositivo de toque. Funciona muito bem quando definido para 1.