É possível que você tenha apenas um padrão incorreto ou uma rota específica em 10.10.10.19? Executar o wireshark nessa máquina enquanto executa novamente o teste para ver o que acontece com os pacotes de retorno parece ser um teste interessante.
Recentemente, terminamos de fazer uma grande mudança de esquema de IP no trabalho e, desde então, notei algumas esquisitices. Primeiro, nossa configuração:
IPCop firewall which has
- Wireless network (completely segregated)
- Firewalled DMZ
- Internal network [eth0] (10.10.10.x)
- OpenVPN network [tun0] (172.16.20.x)
- Internet
Antes da mudança de IP, nossa rede OpenVPN podia falar com nossa rede interna sem nenhum problema. Desde a mudança, temos alguns servidores que não querem mais falar do outro lado da fronteira.
Por exemplo, vou me conectar à VPN com 172.16.20.10 e tentar falar com um servidor em 10.10.10.19. Executando o tcpdump eu vejo os pacotes saírem da minha máquina (executando o wireshark), viajar pelo tun0, viajar pela eth0, apertar 10.10.10.19, e nada volta. Outros servidores funcionam bem na mesma rede (10.10.10.8, por exemplo, funciona bem) e não consigo encontrar uma parte comum entre eles sobre o que faria com que alguns servidores parassem de responder a algumas solicitações.
Eu verifiquei coisas como hosts (allow | deny), pf / iptables, etc, que normalmente filtram o tráfego, mas nenhum deles tem regras de exclusão que parariam o tráfego como este.
Alguma idéia de onde ir a partir daqui?
Solução
As caixas que estavam com o problema tinham, de fato, gateways ruins que foram esquecidos. Fiz as mudanças nos lugares apropriados e tudo parece estar funcionando!
É possível que você tenha apenas um padrão incorreto ou uma rota específica em 10.10.10.19? Executar o wireshark nessa máquina enquanto executa novamente o teste para ver o que acontece com os pacotes de retorno parece ser um teste interessante.
Tags networking openvpn routing ipcop