Captura de pacotes VPN no ASA5505

Question

Acompanhamento de uma pergunta anterior sobre como capturar pacotes no ASA5505 Estou tendo alguma dificuldade em distinguir qual tráfego veio através da VPN e que foi gerado a partir do próprio firewall.

Para descrever o problema, tenho um aplicativo que se conecta a um servidor telnet em uma VPN e está recebendo pacotes de redefinição quando envia dados depois que a conexão ficou inativa por um tempo. Eu gostaria de descobrir de onde essas redefinições se originam; ou é o servidor router / telnet no outro lado de uma VPN ou se é de fato o ASA5505 meu lado que o servidor de aplicativos está por trás. Eu li sobre a série ASA soltando conexões devido a um tempo limite baixo e estou esperando que este seja o problema.

Capturei pacotes no servidor de aplicativos para identificar as redefinições. Eu agora capturei pacotes na interface interna do firewall e as reconfigurações estão lá também. O que eu não consigo fazer é capturar os pacotes que saem do túnel VPN para ver se eles estão lá também. Eu tentei capturar todos os pacotes na interface externa, mas não há nenhum pacote, então acredito que os dados da VPN não podem ser capturados através da interface externa. Alguém sabe como posso capturar os pacotes assim que saem do túnel VPN?

Para capturar os pacotes no interior, combinei com o servidor telnet como fonte:

capture capture1 interface Inside match tcp 171.28.18.50 255.255.255.255 any

Em uma tentativa de capturar pacotes do lado de fora, combinei com qualquer fonte / dest que não seja a conexão ssh que estabeleci para monitorar a captura:

capture capture2 interface Outside match tcp any neq 22 any neq 22

A linha de tempo limite na configuração é:

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

Atualização: Seguindo a sugestão de Shane Madden, capturei pacotes ESP e agora estabeleci que o reset é definitivamente gerado pelo ASA. Agora vou tentar aumentar o timeout conn

Atualização: Ainda não aumentei o timeout conn , mas monitorei a conexão VPN usando o gráfico no ASDM e parece que quando ele está inativo por 30 minutos, o túnel está fechado. Estou suspeitando que quando ela está fechada a conexão TCP está quebrada e ao enviar mais dados na conexão após uma hora o ASA responde com a redefinição. 30 minutos é o padrão para vpn-idle-timeout . Quando eu executo show run | include vpn-idle-timeout , não recebo nada de volta, então só preciso descobrir como definir a variável vpn-idle-timeout .

    

Answer 1

Os pacotes ESP devem capturar muito bem - eles simplesmente não serão muito úteis em termos de ver se há uma redefinição, uma vez que eles ainda estão criptografados (como é a declaração ACL ou de correspondência na aparência de capture ?).

Tentar corresponder os carimbos de data / hora do pacote ESP para redefinir os carimbos de hora do pacote é a melhor maneira que posso pensar para determinar se o ASA está gerando as redefinições.

Pergunta idiota: qual é o seu comando timeout conn no ASA?

    

Answer 2

Esta linha é da configuração atual do ASA?

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

Se sim, então essa é a sua resposta, é o firewall. O TCP não implementa nenhum mecanismo para determinar se uma conexão ainda está ativa ou não (de que estou ciente), portanto, o cliente e o servidor devem, em teoria, estar perfeitamente satisfeitos em manter a sessão mesmo se não houver fluxo de dados. Qualquer um pode implementar keepalives TCP, mas isso teria o efeito oposto do que você está vendo. Um TCP keepalive de qualquer um dos lados faria com que o firewall visse a conexão como ativa.

A terminação normal de uma conexão TCP seria para o host que iniciou a conexão enviar um FIN para a outra extremidade, resultando em uma conexão semifechada da perspectiva do lado de inicialização e (salvo qualquer problema) a conexão TCP prossiga através do processo de fechamento. Este é um processo elegante e não causará um TCP RST. Se um lado da conexão falhar, isso resultará em uma conexão semiaberta, mas, novamente, nenhum dos lados pode detectar isso (que eu saiba) para que nenhum RST seja emitido, exceto pelo firewall. Nenhum dos lados deve enviar um RST devido a uma longa conexão ociosa, a menos que o software em ambos os lados (software cliente telnet ou software servidor telnet) esteja programado para emitir um RST ou algum tipo de comando terminate para conexões ociosas longas.

Como teste (e para poder capturar na interface externa do firewall), considere estabelecer uma sessão de telnet com outro servidor (se disponível) que não transite a conexão VPN e deixe-a inativa. Você provavelmente também poderia testar estabelecendo uma conexão FTP com um servidor externo que não transitasse a conexão VPN e a deixasse inativa. Se você vir o mesmo comportamento do RST, então acho que é seguro apostar que o firewall é a causa.

    

Answer 3

Você observou a aplicação de um tempo limite de TCP na conexão entre o servidor de aplicativos e o servidor de telnet? Eu tentaria aplicá-lo na interface do seu ASA mais próxima do seu servidor de aplicativos, depois de testá-lo.

Aqui está um exemplo: lista de acesso no_tcp_timeout estendido permitir objeto ip objeto do servidor do servidor telnetserver

class-map no_tcp_timeout  lista de acessos no_tcp_timeout

policy-map dmz_policy  class no_tcp_timeout

service-policy dmz_policy interface dmz