[FUG-BR] PF rejeitando conexões

[samuel peres]

2008/8/13 samuel peres <samuel.peres em gmail.com>

>
> 2008/8/13 Luiz Gustavo S. Costa <luizgustavo em luizgustavo.pro.br>
>
>> aumenta mais o valor do nr. de estados...
>>
>> numa dessa ta chegando no limite...
>>
>>
>>
>> 2008/8/13 samuel peres <samuel.peres em gmail.com>:
>> > Saudações a todos da lista,
>> >
>> >                       Estou com um problema muito estranho aqui e não
>> estou
>> > conseguindo encontrar a solução. Tenho um servidor rodando FreeBSD-7.0
>> > (AMD64) e nele tenho o PF fazendo NAT e mais algumas regras de
>> filtragem.
>> > Tudo funcionava perfeitamente, entretanto, na última segunda-feira de
>> forma
>> > misteriosa, o PF começou a rejeitar conexões por volta das 18hs. Para
>> > entender melhor o problema, vejam o exemplo abaixo:
>> >
>> > # ping freebsd.org
>> > PING freebsd.org (69.147.83.40): 56 data bytes
>> > 64 bytes from 69.147.83.40: icmp_seq=0 ttl=51 time=204.782 ms
>> > 64 bytes from 69.147.83.40: icmp_seq=1 ttl=51 time=220.119 ms
>> >
>> > CTRL+C
>> >
>> > # ping freebsd.org
>> > PING freebsd.org (69.147.83.40): 56 data bytes
>> > 64 bytes from 69.147.83.40: icmp_seq=0 ttl=51 time=201.732 ms
>> > 64 bytes from 69.147.83.40: icmp_seq=1 ttl=51 time=199.119 ms
>> >
>> > CTRL+C
>> >
>> > # ping freebsd.org
>> > PING freebsd.org (69.147.83.40): 56 data bytes
>> > ping: sendto: Operation not permitted
>> > ping: sendto: Operation not permitted
>> > 64 bytes from 69.147.83.40: icmp_seq=1 ttl=51 time=182.129 ms
>> >
>> > CTRL+C
>> >
>> > Ou seja, ocasiolnalmente o comando ping retorna "sendto: Operation not
>> > permitted" . Se eu desabilitar o PF o problema não mais acontece,
>> > habilitando novamente volta a acontecer. E detalhe muito importante, no
>> dia
>> > que foi detectado o problema (por volta das 18hs) a rede evidentemente
>> ficou
>> > lenta e a "solução" encontrada no momento foi o famoso reboot (o sistema
>> > estava com um uptime de 71 dias), e concluido o boot do sistema tudo
>> voltou
>> > ao normal. Fiquei preocupado e passei a monitorar o tráfego de todas as
>> > interfaces presentes para ver se achava algo, mas nada, tudo normal. E
>> ontem
>> > (terça-feira) por volta das 18hs novamente o mesmo problema volta a
>> > acontecer, só que dessa vez resolvi não usar o reboot como momentânea
>> > solução. Então pensei em recarregar o PF (/etc/rc.d/pf reload) e feito
>> isso
>> > o sistema voltou a operar normalmente. Como já estou prevendo que o
>> problema
>> > vai voltar de novo (e por incrível que pareça no mesmo horário, porque
>> nesse
>> > momento as coisas continuam normais), me dirijo a vocês para tentar me
>> dar
>> > uma ajuda.
>> >
>> > Observação talvez relativa: Um dia antes (no domingo) foi
>>  re-configurado um
>> > DNS em outro servidor (conectado a interface DMZ) com BIND-9.5.0-P1 e
>> passei
>> > a utilizar VIEW para seperar as zonas.
>> >
>> > No meu /etc/pf.conf tenho a seguinte configuração relacionada a tempo de
>> > execução:
>> >
>> > set optimization normal
>> > set limit { states 40000, frags 30000 }
>> > set timeout { adaptive.start 24000, adaptive.end 48000 }
>> >
>> > A saída de "pfctl -s state | wc -l" sempre me mostra algo em torno de
>> 30000
>> > linhas presentes na tabela de estado.
>> >
>> > Todos adaptadores de rede são PCI Gigabit Intel PRO 100/1000 (device
>> "em").
>> >
>> > Alguém tem alguma dica?
>> >
>> > Desde já obrigado pela atenção
>> >
>> > --
>> > Samuel Peres
>> > -------------------------
>> > Histórico: http://www.fug.com.br/historico/html/freebsd/
>> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>> >
>>
>> Dupliquei o valor de "states". Vou esperar para ver e reporto os
>> resultados para a lista.
>
>
> Valeu pela dica
>
>
Só para deixar documentado na lista mesmo, aumentando o tamanho da tabela de
estado o problema foi resolvido.

Thanks a lot

-- 
Samuel Peres