Temos um firewall Cisco ASA 5510 com o módulo IPS instalado.
Temos um cliente que devemos conectar via VPN à rede deles para trocar arquivos via FTP. Usamos o Cisco VPN Client (versão 5.0.01.0600) em nossas estações de trabalho locais, que estão atrás do firewall e sujeitas ao IPS.
O cliente VPN obtém êxito na conexão com o site remoto. No entanto, quando iniciamos a transferência de arquivos por FTP, podemos fazer o upload de apenas 150K a 200K de dados, então tudo pára. Um minuto depois, a sessão VPN é descartada.
Acho que isolei isso para um problema de IPS desativando temporariamente a Política de Serviço no ASA para o IPS com o seguinte comando:
lista de acesso IPS linha 1 estendida autorização ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 inativa
Depois que este comando foi emitido, eu estabeleci a VPN para o site remoto e obtive êxito na transferência do arquivo inteiro.
Enquanto ainda conectado à sessão VPN e FTP eu emiti o comando para habilitar o IPS:
lista de acesso IPS linha 1 estendida autorização ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
A transferência de arquivos foi tentada novamente e foi novamente bem-sucedida, por isso fechei a sessão de FTP e reabri-a, mantendo a mesma sessão de VPN aberta. Esta transferência de arquivos também foi bem sucedida. Isso me disse que nada com os programas de FTP estava sendo filtrado ou causando o problema. Além disso, usamos o FTP para trocar arquivos com muitos sites todos os dias sem problemas.
Em seguida, desconectei a sessão VPN original, que foi estabelecida quando a lista de acesso estava inativa, e reconectei a sessão VPN, agora com a lista de acesso ativa. Depois de iniciar a transferência por FTP, o arquivo parou após 150K.
Para mim, parece que o IPS está bloqueando ou, de alguma forma, interferindo na configuração inicial da VPN para o site remoto.
Isso só começou a acontecer na semana passada depois que as últimas atualizações de assinaturas IPS foram aplicadas (sig version 407.0). Nossa versão anterior do sig tinha 95 dias, porque o sistema não estava sendo atualizado automaticamente.
Alguma ideia sobre o que poderia estar causando esse problema?
Tente definir a MTU no lado de envio (na verdade, ambos os lados provavelmente precisarão dela). Pode ser que haja um dispositivo que não esteja gerando ou não esteja passando pacotes de descoberta do MTU do caminho corretamente. Se a redução do mtu para, digamos, 1350 em ambas as extremidades o corrigir, investigue se você tem ACLs bloqueando o ICMP.
Não há nada na assinatura 407 relacionada ao FTP. Geralmente, quando você tem problemas de FTP como este, que iniciam e param, geralmente é relacionado ao ftp ativo versus passivo. Qual cliente ftp você está usando? Tente alterá-lo de ativo para passivo em seu cliente de FTP e veja se isso ajuda.
No FTP ativo, o local para o qual você está enviando o FTP inicia a transferência de dados em uma porta diferente da solicitação recebida ... e é por isso que ela geralmente é bloqueada pelo seu firewall.
No FTP passivo, VOCÊ inicia a transferência de dados para a porta diferente e ela funciona porque a maioria dos firewalls permite que tudo que ocorre seja de saída.
Editado para adicionar: As assinaturas são cumulativas. Embora a atualização do 407 não mostre nada relacionado ao FTP, qualquer outra atualização de 95 dias atrás até agora poderia ter alguma coisa. Eu não vou pesquisar todas as atualizações para você descobrir;)
Eu também tenho que perguntar por causa de suas outras perguntas sobre isso ... você está usando as inspeções padrão sobre este 5510, além de desviar o tráfego para o módulo IPS? Se você é, você realmente não precisa.
O fato de começar a transferência indica que não há problema em estabelecer a parte de dados da sessão FTP, que exclui uma ACL que bloqueia a conexão. A própria sessão da VPN caindo durante a grande transferência de arquivos parece apontar para um IPS tomando uma ação na conexão (embora você pensaria que ela terminaria a sessão FTP, mas as ações são configuráveis, então quem sabe?) Se você acha que é Se o seu IPS deixar cair a sessão VPN, você deve ter logs para examinar e alertas do IPS se é seu IPS que a deixa cair. Seu IPS está sendo executado no modo promíscuo (basicamente no modo IDS) ou no modo inline? Tanto quanto eu sei, não pode deixar cair o tráfego se estiver no modo promíscuo desde que recebe somente uma cópia do tráfego. Como ele tem trabalhado sem alterações até o momento (além de uma atualização de assinatura), gostaria de perguntar ao cliente se ele alterou alguma coisa, impedindo a transferência de arquivos grandes em um determinado tamanho; especialmente desde que você disse que você FTP para outros sites sem nenhum problema. Se for apenas com esse cliente, você pode apostar que o problema está no fim.
MTU ou escalonamento de janelas podem ser as razões
Se a transferência de ftp for PASV, você precisa ativar a inspeção de pacotes e as ACLs apropriadas no firewall.
Faça um backup de você executando a configuração primeiro!
Este é o procedimento que fiz em nosso cisco ASA 5505 para inspeção de pacotes
qualquer lista de acesso pode ter várias entradas seus clientes vpn terão sido alocados em uma sub-rede
a linha um do acl para o IPS deve negar a inspeção do tráfego de / para a sub-rede do cliente vpn linha dois do acl deve permitir IPS para outro tráfego pode valer a pena excluir outro tráfego, por ex. isakmp, gre, esp, ah etc de serem inspecionados caso contrário precisaria ver mais da sua configuração
Eu diria que esqueça de usar o FTP ativo ou passivo. Eu odeio a natureza de porta dupla de FTPS e FTP. Em vez disso, baixe o servidor WinSSHD e execute um servidor SFTP em uma única porta: a porta 22. Dessa forma, você está lidando apenas com um único furo.
Conecte-se a ele usando o cliente Tunnelier .
Só tive outra ideia:
Existem 2 tipos de VPN da Cisco: IPSec sobre UDP e IPSec sobre TCP. Provavelmente você está usando a versão TCP, que pode causar perda de pacotes em um cenário NAT. A versão do UDP da VPN é mais estável porque os cabeçalhos TCP são agrupados de maneira diferente. Usando a versão TCP, você pode ter problemas com a tradução NAT. É muito difícil de explicar, mas eu tentaria editar o tipo de VPN do protocolo do lado do cliente ... alterá-lo para IPSec sobre UDP.
Basicamente, as outras respostas neste tópico estão sugerindo a alteração das configurações de MTU para tentar hackear / solucionar os problemas de IPSec sobre TCP que podem surgir em um NAT. Não é assim. A maneira é usar o IPSec sobre o UDP e então o MTU não importa.