Dead Packets

25/01/2010

Troubleshooting ScreenOS 6.2 – SQL ALG

Filed under: ScreenOs,troubleshooting — drak @ 4:53 PM

Novas versões sempre podem trazer surpresas quanto ao comportamento de velhas funcionalidades ou adição de novas, uma característica interessante presente no ScreenOS 6.2 (mas que foi introduzida antes, não sei exatamente quando) é o ALG, ou Application Layer Gateway.

Esta funcionalidade é responsável por controlar o comportamento global do firewall para certos protocolos (FTP, SQL, PPTP, etc), como abertura de portas efêmeras (acima de 1024) para a sessão de dados. Porém como nem todos os desenvolvedores seguem as regras da RFC adequada ao protocolo ou até mesmo por bugs do ScreenOS esta funcionalidade às vezes precisa ser desativada.

Agora, o caso: um cliente teve seu firewall atualizado de 5.4r8 para 6.2r4 e inicialmente reclamou de lentidão na rede, após análise de perda de pacotes, confirmação das velocidades das portas no FW x switch e traceroutes indicando o caminho do tráfego, tudo indicou que o ambiente estava normal.

Dias depois o cliente volta a reclamar, porém dessa vez ele informa que, através de um túnel SSH ele conseguiu fazer com que a aplicação, que faz uma requisição ao BD Oracle, funcionasse normalmente, de posse dessas informações inicio um debug no firewall, segue abaixo trecho da captura.

ssgFW(M)-> set ffilter src-ip 10.0.2.2 dst-ip 172.16.4.14
ssgFW(M)-> clear db
ssgFW(M)-> debug flow basic
ssgFW(M)-> get db str

**** jump to packet:10.0.2.2->172.16.4.14
 flow_decap_vector IPv4 process
 flow packet already have session.
 flow session id 47490
 flow_main_body_vector in ifp ethernet0/0 out ifp ethernet0/1
 flow vector index 0x3ab, vector addr 0x518d8e4, orig vector 0x518d8e4
 vsd 0 is active
 av/uf/voip checking.
 post addr xlation: 10.0.2.2->172.16.4.14.
 update policy out counter info.
 packet send out to 0015c5ebed63 through ethernet0/1
 **** pak processing end.
after ALG, drop temp packet(550c924).
 **** pak processing end.
****** 10166.0: <DMZ/ethernet0/1> packet received [1500]******
 ipid = 39074(98a2), @1d544914
 packet passed sanity check.
 flow_decap_vector IPv4 process
 ethernet0/1:172.16.4.14/1521->10.0.2.2/2171,6<Root>
 existing session found. sess token 13
 flow got session.
 flow session id 47490
 flow_main_body_vector in ifp ethernet0/1 out ifp N/A
 flow vector index 0x3ab, vector addr 0x518d8e4, orig vector 0x518d8e4
 vsd 0 is active
 av/uf/voip checking.
 asp vector processing state: 2
ASP inject packet from ethernet0/0

Estou acostumado a realizar o debug (que mostra o processamento do pacote pelo firewall) e percebi que havia algo estranho. A mensagem “after ALG, drop temp packet(550c924).” não era comum em outras capturas e por isso resolvi investigar um pouco mais.

Ativei o log (tanto no fim quanto no início da sessão) na regra de acesso e solicitei novo teste, percebi que havia um timeout 2s após a primeira conexão, além disso quando a requisição estava encapsulada em SSH a aplicação funcionava, por estes motivos desconfiei do tempo de timeout do protocolo (SQL*Net V2, TCP/1521) e o alterei, sem sucesso.

Encontrei algumas informações no KB da Juniper relacionada à funcionalidade ALG, experimentei desativar o ALG desse protocolo, utilizei o seguinte comando:

ssgFW(M)-> unset alg sql enable

Solicitei novo teste, com a seguinte captura:

****** 11049.0: <Trust/ethernet0/0> packet received [52]******
 ipid = 61246(ef3e), @1d51f114
 packet passed sanity check.
 flow_decap_vector IPv4 process
 ethernet0/0:10.0.2.2/2226->172.16.4.14/1521,6<Root>
 no session found
 flow_first_sanity_check: in <ethernet0/0>, out <N/A>
 chose interface ethernet0/0 as incoming nat if.
 flow_first_routing: in <ethernet0/0>, out <N/A>
 search route to (ethernet0/0, 10.0.2.2->172.16.4.14) in vr trust-vr for vsd-0/flag-0/ifp-null
 [ Dest] 3.route 172.16.4.14->172.16.4.14, to ethernet0/1
 routed (x_dst_ip 172.16.4.14) from ethernet0/0 (ethernet0/0 in 0) to ethernet0/1
 policy search from zone 2-> zone 3
 policy_flow_search  policy search nat_crt from zone 2-> zone 3
 RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 172.16.4.14, port 1521, proto 6)
 No SW RPC rule match, search HW rule
swrs_search_ip: policy matched id/idx/action = 150/0/0x9
 Permitted by policy 150
 No src xlate   choose interface ethernet0/1 as outgoing phy if
 check nsrp pak fwd: in_tun=0xffffffff, VSD 0 for out ifp ethernet0/1
 vsd 0 is active
 no loop on ifp ethernet0/1.
 session application type 64, name SQLNETV2, nas_id 0, timeout 131070sec
ALG vector is not attached
 service lookup identified service 0.
 flow_first_final_check: in <ethernet0/0>, out <ethernet0/1>
 existing vector list 123-815f334.
 Session (id:46885) created for first pak 123
 flow_first_install_session======>
 route to 172.16.4.14
 arp entry found for 172.16.4.14
 ifp2 ethernet0/1, out_ifp ethernet0/1, flag 00800800, tunnel ffffffff, rc 1
 outgoing wing prepared, ready
 handle cleartext reverse route
 search route to (ethernet0/1, 172.16.4.14->10.0.2.2) in vr trust-vr for vsd-0/flag-3000/ifp-ethernet0/0
 [ Dest] 10.route 10.0.2.2->192.168.8.2, to ethernet0/0
 route to 192.168.8.2
 arp entry found for 192.168.8.2
 ifp2 ethernet0/0, out_ifp ethernet0/0, flag 00800801, tunnel ffffffff, rc 1
 flow got session.
 flow session id 46885
 flow_main_body_vector in ifp ethernet0/0 out ifp ethernet0/1
 flow vector index 0x123, vector addr 0x815f334, orig vector 0x815f334
 vsd 0 is active
 tcp seq check.
 Got syn, 10.0.2.2(2226)->172.16.4.14(1521), nspflag 0x801801, 0x800800
 post addr xlation: 10.0.2.2->172.16.4.14.
 packet send out to 0015c5ebed63 through ethernet0/1
****** 11049.0: <DMZ/ethernet0/1> packet received [52]******
 ipid = 0(0000), @1d58a914
 packet passed sanity check.
 flow_decap_vector IPv4 process
 ethernet0/1:172.16.4.14/1521->10.0.2.2/2226,6<Root>
 existing session found. sess token 13
 flow got session.
 flow session id 46885
 flow_main_body_vector in ifp ethernet0/1 out ifp N/A
 flow vector index 0x123, vector addr 0x815f334, orig vector 0x815f334
 vsd 0 is active
 tcp seq check.
 Got syn_ack, 172.16.4.14(1521)->10.0.2.2(2226), nspflag 0x801800, 0x801801
 post addr xlation: 172.16.4.14->10.0.2.2.
 packet send out to 0003a0284406 through ethernet0/0

Percebi que o output havia mudado e estava parecido com o que eu estou acostumado, notei também o detalhe “ALG vector is not attached”.

Após o teste o cliente reportou que a aplicação estava normal, problema solucionado.

Referências
What is an ALG (Application Layer Gateway)?

What happens when I turn off a ALG (Application Layer Gateway)

Anúncios

Deixe um comentário »

Nenhum comentário ainda.

RSS feed for comments on this post. TrackBack URI

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Blog no WordPress.com.

%d blogueiros gostam disto: