Eu tenho a seguinte configuração:
LAN 01: 192.168.16.0/24 (LAN for internal servers)
LAN 02: 192.168.67.0/24 (LAN for workstations)
WAN: X.X.X.X
E então:
PFSENSE LAN IP: 192.168.16.1
PFSENSE LAN IP: 192.168.67.1 (it's a virtual IP)
LAN 01eLAN 02estão fisicamente conectados (ou seja, no mesmo switch. Eu sei que deveria usar LANs separadas ou pelo menos VLANs neles, mas não posso alterar facilmente essa configuração por enquanto).
Eu tenho uma instalação do PFSENSE (2.2) funcionando onde os computadores emLAN 02obtenha seus endereços IP de um SERVIDOR DHCP e use o PFSENSE como gateway padrão.
Aqui está o meu problema:
Se eu sentar em um computador residente emLAN 02e eu ssh (ou qualquer outro protocolo persistente) em um servidor residente emLAN 01assim:
$ ssh -l myself 192.168.16.25
Eu me conecto sem problemas. A conexão dura algo entre 20 e 30 segundos e depois cai consistentemente.
Então minha pergunta é:O que posso fazer para evitar a queda da conexão?
Fiz um tcpdump dos dois lados e, em algum momento, os pacotes começaram a ficar duplicados. Se parece com isso:
Eu tenho essa opção habilitada e pensei que ajudaria, mas não ajudou.
Devo mencionar que exatamente esta mesma configuração, usando um FIREWALL LINUX (iptables) funciona perfeitamente.
Alguma ideia?
Responder1
Suponho que sua listagem de LAN1 e LAN2 como 192.168.1.0/24 está errada, pois a captura mostra que um é 192.168.16.0 e o outro é 192.168.67.0, aparentemente, espero que ambos/24s.
A opção de filtragem de rota estática não tem aplicabilidade aqui.
Suponho que você tenha redes sobrepostas (não uma máscara /24 em ambas, talvez /16 em alguns hosts) ou um dos sistemas afetados tenha hospedagem dupla em ambas as redes, o que causa roteamento assimétrico.
Responder2
Eu tive um problema muito semelhante e o problema era essencialmente uma variação do roteamento assimétrico.
Com minha topologia, tenho uma caixa PFSENSE com 2 interfaces LAN - ambas/24s, mas sub-redes definitivamente diferentes. Tenho então um switch L2\L3 que conecta ambas as interfaces ao resto da rede em VLANs diferentes. Também pendurados nessa chave estão os usuários com fio e um segmento que possui todos os usuários sem fio. Os usuários com fio estão em uma sub-rede\VLAN e os sem fio em outra - e ambas as sub-redes existem na caixa PFSENSE. Todos os endpoints usam o IP PFSENSE para suas respectivas sub-redes como DG. E por fim, o switch também possui um IP em ambas as sub-redes mencionadas.
Meu problema era que se eu estivesse conectado via wireless e SSH ao switch, eu conectaria bem e cairia em 20 a 30 segundos. Como você provavelmente já percebeu, como o switch tinha um IP na mesma sub-rede da minha máquina, os pacotes de retorno do switch iriam direto para a minha máquina, em vez de seguir o mesmo caminho dos pacotes da minha máquina. A mudança basicamente apenas contornaria a caixa PFSENSE.
Em muitas situações, isso poderia funcionar bem, especialmente para intermediários sem estado e/ou sessões UDP. No entanto, a caixa PFSENSE é um dispositivo com estado, portanto, após alguns segundos, o PFSENSE não vê nenhuma resposta ao TCP OPEN e acaba eliminando o estado. Para confirmar, você pode ajustar o valor do tempo limite TCP OPEN do PFSENSE (Sistema -> Avançado -> Tempos limite de estado) e então observar que o tempo que leva para a sessão SSH cair seguirá o que você definiu. O padrão para esse valor é, como esperado, 30s. Ao remover o IP relevante do switch - BAM - o problema foi corrigido.
Embora não seja mencionado especificamente na topologia descrita do OP, suspeito que possa haver uma mudança (ou similar) entre os pontos de extremidade relevantes. Talvez não, mas se for assim, pode ser o mesmo problema que tive aqui. Como alternativa, se o servidor no topo do OP tiver hospedagem dupla, esse problema ocorrerá.