Solução de problemas de proxy no Cisco Secure Firewall Management Center (FMC)

Introdução

• Requisitos

• Componentes Utilizados

Configuração

Troubleshooting

Verificação

Problemas conhecidos

• Restrições de ACL de proxy

• O proxy falha no download do arquivo (tempo limite/transferência incompleta)

• O proxy falha no download do arquivo (problema de MTU)

Referências

Introdução

Este documento descreve a configuração de um proxy no FMC para permitir que os usuários se conectem à Internet através de um servidor intermediário, aumentando a segurança e, às vezes, melhorando o desempenho. Este artigo orienta você durante as etapas de configuração de um proxy no FMC e fornece dicas de solução de problemas comuns.

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Cisco Secure Firewall Management Center (FMC)

• Proxy

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• FMC 7.4.x

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Configuração

Configure o proxy http da rede na GUI do FMC:

Faça login na GUI do FMC > Escolha System > Configuration e escolha Management Interfaces.

Note: Não há suporte para proxies que usam a autenticação NT LAN Manager (NTLM). Se você usar o Smart Licensing, o FQDN do proxy não poderá ter mais de 64 caracteres.

Na área Proxy, defina as configurações do proxy HTTP.

O centro de gerenciamento é configurado para se conectar diretamente à Internet nas portas TCP/443 (HTTPS) e TCP/80 (HTTP). Você pode usar um servidor proxy, para o qual você pode se autenticar via HTTP Digest.

• Marque a caixa de seleçãoHabilitado.
• No campo HTTP Proxyfield, insira o endereço IP ou o nome de domínio totalmente qualificado do servidor proxy.
• No campoPorta, insira um número de porta.
• Forneça credenciais de autenticação escolhendo Usar autenticação de proxy e forneça um Nome de usuário e uma Senha.
• Click Save.

Troubleshooting

Obtenha acesso ao FMC CLI e ao modo especialista e verifique iprep_proxy.conf para garantir que as configurações de proxy estejam corretas:

admin@fmc:~$ cat /etc/sf/iprep_proxy.conf 
iprep_proxy {
PROXY_HOST 10.10.10.1;
PROXY_PORT 80;
}

Verifique as conexões ativas para verificar a conexão proxy ativa:

admin@fmc:~$ netstat -na | grep 10.10.10.1 
tcp 0 0 10.40.40.1:40220 10.10.10.1:80 ESTABLISHED

Usando o comando curl, verifique os detalhes da solicitação e a resposta do proxy. Se você receber a resposta: HTTP/1.1 200 Connection established, isso indica que o FMC está enviando e recebendo tráfego com êxito através do proxy. 

admin@fmc:~$ curl -x http://10.10.10.1:80 -I https://tools.cisco.com
HTTP/1.1 200 Connection established

Se você configurou o nome de usuário e a senha para o proxy, verifique a autenticação e a resposta do proxy:

curl -u proxyuser:proxypass --proxy http://proxy.example.com:80 https://example.com

Ao executar um comando curl com um proxy, tal como curl -x http://proxy:80 -I https://tools.cisco.com, uma série de interações de rede esperadas ocorrem, que podem ser observadas através da captura de pacotes (tcpdump). Esta é uma visão geral de alto nível do processo, enriquecida com saídas reais de tcpdump:

Início do handshake TCP:
O cliente (FMC) inicia uma conexão TCP com o servidor proxy na porta 80, enviando um pacote SYN. O proxy responde com um SYN-ACK e o cliente conclui o handshake com um ACK. Isso estabelece a sessão TCP sobre a qual a comunicação HTTP prossegue.

Exemplo de saída de tcpdump:

10:20:58.987654 IP client.54321 > proxy.80: Flags [S], seq 0, win 64240, options [mss 1460], length 0 
10:20:58.987700 IP proxy.80 > client.54321: Flags [S.], seq 0, ack 1, win 65160, options [mss 1460], length 0 
10:20:58.987734 IP client.54321 > proxy.80: Flags [.], ack 1, win 64240, length 0

Solicitação HTTP CONNECT:
Uma vez estabelecida a conexão TCP, o cliente envia uma solicitação HTTP CONNECT ao proxy, instruindo-o a criar um túnel para o servidor HTTPS de destino (tools.cisco.com:443). Essa solicitação permite que o cliente negocie uma sessão TLS fim-a-fim por meio do proxy.

Exemplo de tcpdump (HTTP decodificado):

CONNECT tools.cisco.com:443 HTTP/1.1 
Host: tools.cisco.com:443 
User-Agent: curl/8.5.0 
Proxy-Connection: Keep-Alive

Confirmação de estabelecimento de conexão:
O proxy responde com uma resposta HTTP/1.1 200 Connection estabelecida, indicando que o túnel para o servidor de destino foi criado com êxito. Isso significa que o proxy está agora agindo como um relé, encaminhando tráfego criptografado entre o cliente e tools.cisco.com.

Exemplo de tcpdump:

HTTP/1.1 200 Connection established

Comunicação HTTPS via túnel:
Após a resposta CONNECT bem-sucedida, o cliente inicia o handshake SSL/TLS diretamente com tools.cisco.com pelo túnel estabelecido. Como esse tráfego é criptografado, o conteúdo não fica visível no tcpdump, mas os comprimentos e os tempos dos pacotes são observáveis, incluindo os pacotes Hello do cliente TLS e Hello do servidor.

Exemplo de tcpdump:

10:20:59.123456 IP client.54321 > proxy.80: Flags [P.], length 517 (Client Hello) 
10:20:59.123789 IP proxy.80 > client.54321: Flags [P.], length 1514 (Server Hello)

Tratamento do redirecionamento HTTP (302 encontrados):
Como parte da comunicação HTTPS, o cliente solicita o recurso de tools.cisco.com. O servidor responde com um redirecionamento HTTP/1.1 302 Encontrado para outro URL (https://tools.cisco.com/healthcheck), que o cliente pode seguir dependendo dos parâmetros curl e da finalidade da solicitação. Embora esse redirecionamento ocorra dentro da sessão TLS criptografada e não seja diretamente visível, é esperado comportamento e pode ser observado se o tráfego TLS for descriptografado.

O tráfego de redirecionamento criptografado seria semelhante a este:

10:21:00.123000 IP client.54321 > proxy.80: Flags [P.], length 517 (Encrypted Application Data) 
10:21:00.123045 IP proxy.80 > client.54321: Flags [P.], length 317 (Encrypted Application Data)

Desmontagem da conexão:
Quando a troca estiver concluída, o cliente e o proxy fecham normalmente a conexão TCP trocando pacotes FIN e ACK, garantindo o término adequado da sessão.

Exemplo de saída de tcpdump:

10:21:05.000111 IP client.54321 > proxy.80: Flags [F.], seq 1234, ack 5678, length 0 
10:21:05.000120 IP proxy.80 > client.54321: Flags [F.], seq 5678, ack 1235, length 0 
10:21:05.000125 IP client.54321 > proxy.80: Flags [.], ack 5679, length 0

Tip: Analisando a saída tcpdump, você pode verificar se a solicitação HTTPS através do proxy explícito segue o fluxo esperado: Handshake TCP, solicitação CONNECT, estabelecimento de túnel, handshake TLS, comunicação criptografada (incluindo possíveis redirecionamentos) e fechamento de conexão grátis. Isso confirma que a interação do proxy e do cliente está funcionando conforme projetado e ajuda a identificar quaisquer problemas no fluxo, como falhas no tunelamento ou na negociação SSL.

O FMC (10.40.40.1) estabelece um handshake TCP bem-sucedido com o Proxy (10.10.10.1) na porta 80, seguido por um HTTP CONNECT para o servidor (72.163.4.161) na porta 443. O servidor responde com uma mensagem HTTP 200 Connection established. O handshake TLS é concluído e os dados fluem corretamente. Finalmente, a conexão TCP termina normalmente (FIN).

Problemas conhecidos

Restrições de ACL de proxy

Se houver um problema de permissão (como uma lista de acesso no proxy), você poderá observar isso por meio da captura de pacotes (tcpdump). Esta é uma explicação de alto nível do cenário de falha, juntamente com saídas de exemplo tcpdump:

Início do handshake TCP:
O cliente (Firepower) começa estabelecendo uma conexão TCP com o proxy na porta 80. O handshake TCP (SYN, SYN-ACK, ACK) é concluído com êxito, o que significa que o proxy está acessível.

Exemplo de saída de tcpdump:

10:20:58.987654 IP client.54321 > proxy.80: Flags [S], seq 0, win 64240, options [mss 1460], length 0 
10:20:58.987700 IP proxy.80 > client.54321: Flags [S.], seq 0, ack 1, win 65160, options [mss 1460], length 0 
10:20:58.987734 IP client.54321 > proxy.80: Flags [.], ack 1, win 64240, length 0

Solicitação HTTP CONNECT:
Uma vez conectado, o cliente envia uma solicitação HTTP CONNECT ao proxy, solicitando que ele crie um túnel para tools.cisco.com:443.

Exemplo de tcpdump (HTTP decodificado):

CONNECT tools.cisco.com:443 HTTP/1.1 
Host: tools.cisco.com:443 
User-Agent: curl/8.5.0 
Proxy-Connection: Keep-Alive

Resposta de erro do proxy:

Em vez de permitir o túnel, o proxy nega a solicitação, provavelmente devido a uma lista de acesso (ACL) que não permite esse tráfego. O proxy responde com um erro como 403 Forbidden ou 502 Bad Gateway.

Exemplo de saída tcpdump mostrando erro:

HTTP/1.1 403 Forbidden 
Content-Type: text/html 
Content-Length: 123 
Connection: close

Desmontagem da conexão:
Após enviar a mensagem de erro, o proxy fecha a conexão e ambos os lados trocam pacotes FIN/ACK.

Exemplo de saída de tcpdump:

10:21:05.000111 IP client.54321 > proxy.80: Flags [F.], seq 1234, ack 5678, length 0 
10:21:05.000120 IP proxy.80 > client.54321: Flags [F.], seq 5678, ack 1235, length 0 
10:21:05.000125 IP client.54321 > proxy.80: Flags [.], ack 5679, length 0

Tip: No tcpdump, você pode ver que, embora a conexão TCP e a solicitação HTTP CONNECT tenham sido bem-sucedidas, o proxy negou a configuração do túnel. Isso geralmente indica que o proxy tem uma ACL ou restrição de permissão impedindo a passagem do tráfego.

Falha no download do proxy (Tempo limite/Transferência incompleta)

Nesse cenário, o FMC se conecta com êxito ao proxy e inicia o download do arquivo, mas a transferência expira ou não é concluída. Isso geralmente ocorre devido à inspeção de proxy, tempos limite ou limites de tamanho de arquivo no proxy.

Iniciação de handshake TCP
O FMC inicia uma conexão TCP com o proxy na porta 80 e o handshake é concluído com êxito.
Exemplo de saída de tcpdump:

10:20:58.987654 IP fmc.54321 > proxy.80: Flags [S], seq 0, win 64240, options [mss 1460], length 0
10:20:58.987700 IP proxy.80 > fmc.54321: Flags [S.], seq 0, ack 1, win 65160, options [mss 1460], length 0
10:20:58.987734 IP fmc.54321 > proxy.80: Flags [.], ack 1, win 64240, length 0

Solicitação HTTP CONNECT
O FMC envia uma solicitação HTTP CONNECT ao proxy para alcançar o destino externo.
Exemplo de tcpdump (HTTP decodificado):

CONNECT tools.cisco.com:443 HTTP/1.1
Host: tools.cisco.com:443
User-Agent: FMC-Agent
Proxy-Connection: Keep-Alive

Estabelecimento de túnel e handshake TLS
O proxy responde com a conexão HTTP/1.1 200 estabelecida, permitindo que o handshake TLS comece.

Exemplo de saída de tcpdump:

HTTP/1.1 200 Connection established
10:20:59.123456 IP fmc.54321 > proxy.80: Flags [P.], length 517 (Client Hello)
10:20:59.123789 IP proxy.80 > fmc.54321: Flags [P.], length 1514 (Server Hello)

Tempo limite ou download incompleto
Após iniciar a transferência de arquivo, o download é interrompido ou não é concluído, levando a um tempo limite. A conexão permanece ociosa.
As possíveis razões incluem:

• Atrasos ou filtragem na inspeção de proxy.
• Tempos limite de proxy para transferências longas.
• Limites de tamanho de arquivo impostos pelo proxy.

Exemplo de tcpdump mostrando inatividade:

10:21:00.456000 IP fmc.54321 > proxy.80: Flags [P.], length 1440 # FMC sending data
# No response from proxy, connection goes idle...
# After a while, FMC may close the connection or retry.

Tip: O FMC inicia o download, mas não é concluído devido a tempos limite ou transferências incompletas, geralmente causadas por filtragem de proxy ou restrições de tamanho de arquivo.

O proxy falha no download do arquivo (problema de MTU)

Nesse caso, o FMC se conecta ao proxy e inicia o download dos arquivos, mas a sessão falha devido a problemas de MTU. Esses problemas causam fragmentação de pacotes ou perda de pacotes, especialmente com arquivos grandes ou handshakes SSL/TLS.

Iniciação de handshake TCP
O FMC inicia o handshake TCP com o proxy, que é bem-sucedido.
Exemplo de saída de tcpdump:

10:20:58.987654 IP fmc.54321 > proxy.80: Flags [S], seq 0, win 64240, options [mss 1460], length 0
10:20:58.987700 IP proxy.80 > fmc.54321: Flags [S.], seq 0, ack 1, win 65160, options [mss 1460], length 0
10:20:58.987734 IP fmc.54321 > proxy.80: Flags [.], ack 1, win 64240, length 0

Solicitação HTTP CONNECT e estabelecimento de túnel
O FMC envia uma solicitação HTTP CONNECT e o proxy responde, permitindo que o túnel seja estabelecido.
Exemplo de tcpdump (HTTP decodificado):

CONNECT tools.cisco.com:443 HTTP/1.1
Host: tools.cisco.com:443
User-Agent: FMC-Agent
Proxy-Connection: Keep-Alive

O handshake TLS começa
O FMC e o tools.cisco.com começam a negociar SSL/TLS e os pacotes iniciais são trocados.
Exemplo de saída de tcpdump:

HTTP/1.1 200 Connection established
10:20:59.123456 IP fmc.54321 > proxy.80: Flags [P.], length 517 (Client Hello)
10:20:59.123789 IP proxy.80 > fmc.54321: Flags [P.], length 1514 (Server Hello)

Fragmentação ou queda de pacote devido à MTU
Quando o FMC ou o servidor tenta enviar pacotes grandes, problemas de MTU causam fragmentação de pacote ou quedas de pacote, resultando em falhas de transferência de arquivo ou negociação de TLS.
Isso geralmente ocorre quando a MTU entre o FMC e o proxy (ou entre o proxy e a Internet) está definida incorretamente ou é muito pequena.
Exemplo de tcpdump mostrando a tentativa de fragmentação:

10:21:00.456000 IP fmc.54321 > proxy.80: Flags [P.], length 1440 # Large packet
10:21:00.456123 IP proxy.80 > fmc.54321: Flags [R], seq X, win 0, length 0 # Proxy resets connection due to MTU issue

Tip: O problema de MTU resulta em pacotes descartados ou fragmentados, que interrompem o handshake TLS ou fazem com que os downloads de arquivos falhem. Isso é comumente visto quando a inspeção SSL ou a fragmentação de pacote ocorre devido a configurações incorretas de MTU.

Em um cenário de falha, o FMC obtém o CONNECT sem HTTP 200, com retransmissões e FINs confirmando que não há troca de TLS/dados, possivelmente devido a problemas de MTU ou um problema de proxy/upstream.

Ao usar curl, você pode encontrar vários códigos de resposta HTTP indicando problemas no servidor ou erros de autenticação. Esta é uma lista dos códigos de erro mais comuns e seus significados:

Referências

Notas de versão do Cisco Secure Firewall Threat Defense, versão 7.4.x