Pode sim De fato, é possível usar os 3 filtros juntos (IPF, PF, e IPFW). Mas basta um block/deny num deles para negar a comunicação.
Nada te impede de usar o nat do PF, em conjunto com os filtros do IPFW. É possível usar o filtro e nat do PF, por exemplo, em conjunto dos recursos avançados do IPFW (jail, user,...). Em 13 de outubro de 2010 11:55, Marcelo Gondim <gon...@linuxinfo.com.br> escreveu: > Opa Alessandro, > > Eu poderia em um primeiro momento usar apenas o NAT do pf junto com as > regras de filtragem do ipfw? Ou teria que fazer todas as regras no pf mesmo? > > []´s > > -------------------------------------------------- > From: "Alessandro de Souza Rocha" <etherlin...@gmail.com> > Sent: Wednesday, October 13, 2010 9:56 AM > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" > <freebsd@fug.com.br> > Subject: Re: [FUG-BR]Performance estranha e quedas na conexão > >> porque vc nao usa o pf pra fazer nat ao inveis de usa natd. >> >> Em 13 de outubro de 2010 09:33, Renato Frederick >> <ren...@frederick.eti.br> escreveu: >>> Precisa fazer o divert "from any to any"? >>> >>> O ideal seria 2 regras, uma para out, outra para in e especificando >>> endereços de origem/destino. >>> >>> Outra dúvida, os clientes internos precisam sair com nat pro pgsql? >>> >>> talvez reescrever a regra seja interessante, até para economia de >>> cpu/memória(já que um divert all from any to any empurra pro natd tudo >>> que >>> passe pelo firewall e venha de ip´s reservados). >>> >>> []s >>> >>> >>> >>> >>> >>> -----Mensagem Original----- >>> From: Antonio Modesto >>> Sent: Wednesday, October 13, 2010 8:49 AM >>> To: Lista Brasileira deDiscussãosobre FreeBSD (FUG-BR) >>> Subject: Re: [FUG-BR]Performance estranha e quedas na conexão >>> >>> Tambem tive um problema parecido, e também eram regras erradas no NATD. >>> >>> On Tue, 2010-10-12 at 23:52 -0300, Marcelo Gondim wrote: >>> >>>> Opa fazendo testes aqui em casa já descobri o problema da queda de >>>> conexão >>>> que pode resolver tanto o problema do putty quanto do PostgreSQL. O >>>> problema >>>> está mesmo no NAT. Estava fazendo a regra sem o keep-state e fazia como >>>> stateless a saída e a entrada da comunicação dessa forma fazendo uma >>>> regra >>>> como abaixo resolveu o problema das quedas e quem sabe também poderá >>>> resolver o problema da performance. :) >>>> >>>> ipfw add divert 8668 all from any to any out via re0 keep-state >>>> >>>> Dessa forma a conexão com o putty se manteve e não caiu mais como se >>>> fosse >>>> um time-out >>>> >>>> Assim que tiver feito os outros testes avisarei aqui. :) >>>> >>>> -------------------------------------------------- >>>> From: "Marcelo Gondim" <gon...@linuxinfo.com.br> >>>> Sent: Tuesday, October 12, 2010 10:38 PM >>>> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" >>>> <freebsd@fug.com.br> >>>> Subject: Re: [FUG-BR]Performance estranha e quedas na conexão >>>> >>>> > Oi Rodrigo, >>>> > >>>> > -------------------------------------------------- >>>> > From: "Rodrigo Mosconi" <free...@mosconi.mat.br> >>>> > Sent: Tuesday, October 12, 2010 2:22 PM >>>> > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" >>>> > <freebsd@fug.com.br> >>>> > Subject: Re: [FUG-BR]Performance estranha e quedas na conexão >>>> > >>>> >> Marcelo, >>>> >> >>>> >> Em 12 de outubro de 2010 01:18, Marcelo Gondim >>>> >> <gon...@linuxinfo.com.br> escreveu: >>>> >>> Olá pessoal, >>>> >>> >>>> >>> Estou fazendo uma migração aqui de um servidor Firewall Linux CentOS >>>> >>> 5.5 >>>> >>> para um FreeBSD 8.1-STABLE. Passei o dia fazendo todas as regras >>>> >>> equivalentes entre o Netfilter/IPTables para o ipfw/natd. Todos os >>>> >>> acessos >>>> >>> funcionaram, tanto filtros quanto NAT, mas aconteceram 2 coisas >>>> >>> estranhas >>>> >>> e >>>> >>> vim aqui recorrer à experiência de vocês, que tem mais tempo e >>>> >>> bagagem >>>> >>> com >>>> >>> FreeBSD. :) >>>> >>> >>>> >>> A configuração básica é essa: >>>> >>> >>>> >>> Internet <-----> Firewall FreeBSD <-----> rede do cliente (Aplicação >>>> >>> em >>>> >>> Delphi) >>>> >>> | >>>> >>> | >>>> >>> | >>>> >>> Servidor PostgreSQL >>>> >>> >>>> >>> 1) Primeira coisa que aconteceu, o acesso da aplicação Delphi dele >>>> >>> para >>>> >>> a >>>> >>> base PostgreSQL ficou muito mas muito mais lento e no Firewall não >>>> >>> estou >>>> >>> fazendo qualquer controle de tráfego. Achei estranho e voltei para o >>>> >>> CentOS >>>> >>> e a aplicação voltou ao normal e sua velocidade. >>>> >>> >>>> >>> 2) Outra coisa estranha que ocorre: o cliente está com aplicação >>>> >>> conectada >>>> >>> na base e depois de um tempo sem fazer nada no sistema, quando ele >>>> >>> vai >>>> >>> fazer >>>> >>> algo, dá um erro de SQL dizendo que o servidor perdeu a conexão como >>>> >>> se >>>> >>> a >>>> >>> conexão tivesse sido fechada por time-out. Isso também ocorre com o >>>> >>> putty, >>>> >>> tipo fiz um acesso ssh pelo putty no servidor postgresql. Se eu >>>> >>> ficar >>>> >>> um >>>> >>> tempo com o putty parado, sem digitar nada, a conexão cai também. >>>> >>> Fiz >>>> >>> o >>>> >>> mesmo teste voltando para o CentOS e os erros não ocorreram e nem a >>>> >>> conexão >>>> >>> ssh caiu no putty. >>>> >>> >>>> >>> Alguém saberia dar uma luz sobre essa situação, tipo se a velocidade >>>> >>> estaria >>>> >>> relacionada à algum tunning e se essas quedas na conexão tcp por >>>> >>> time-out >>>> >>> tem algum ajuste também? >>>> >>> >>>> >>> []´s a todos e agradeço desde já qualquer luz :) >>>> >> >>>> >> 1- Há nat entre os clientes e a base PG? É um cenário parecido com o >>>> >> email anterior da lista? >>>> >> >>>> > >>>> > Sim sim é mesmo cenário. Existe o nat entre o cliente e a base, no >>>> > programa >>>> > dele ele faz o acesso ao IP público e o mesmo é traduzido pelo nat >>>> > para >>>> > 192.168.10.2. >>>> > O nat pode estar causando essa lentidão? >>>> > >>>> >> 2- O acesso à internet é IP dinâmico? Caso positivo, o script de FW é >>>> >> executado >>>> >> o link sobe? Um flush do ipfw limpa todos os estados, o que derruba >>>> >> as conexões. >>>> > >>>> > O IP é fixo e o script faz um ipfw -f flush antes de carregar as >>>> > regras. >>>> > Até >>>> > pensei na hora que a conexão com a base havia caído no momento em que >>>> > rodei >>>> > o script mas mesmo sem rodar o script a conexão cai. :( será que >>>> > pode >>>> > ter >>>> > à ver com o polling como coloquei num e-mail anterior? Também vou >>>> > fazer >>>> > o >>>> > teste de retirar todo o Firewall e deixar só o NAT para ver se a >>>> > performance >>>> > normaliza e as conexões ficam estáveis. >>>> > >>>> >> >>>> >> 3- Já pensou em usar o PF no lugar do IPFW? >>>> >> >>>> > >>>> > Poderia até usar mas achei estranho o que aconteceu e acredito que >>>> > seja >>>> > alguma falha na minha configuração e não no ipfw em si. De qualquer >>>> > forma >>>> > pretendo estudar o pf como outra alternativa à firewall. :) >>>> > >>>> >> Att, >>>> >> >>>> >> Rodrigo Mosconi >>>> >> >>>> >>> >>>> > >>>> > >>>> > ------------------------- >>>> > Histórico: http://www.fug.com.br/historico/html/freebsd/ >>>> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>>> >>>> ------------------------- >>>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>>> >>> >>> Antonio Modesto >>> >>> Gerente de TI >>> >>> >>> Praça Getúlio Vargas, 77 – Sala 308 – Centro >>> >>> Santo Antônio do Monte – MG – CEP: 35560-000 >>> (37) 3281-2800 >>> >>> isimp...@isimples.com.brhttp://www.isimples.com.br >>> >>> >>> Aviso:Esta mensagem e quaisquer arquivos em anexo podem conter >>> informações confidenciais e/ou >>> >>> privilegiadas. Se você não for o destinatário ou a pessoa autorizada a >>> receber esta mensagem, por favor, não >>> >>> leia, copie, repasse, imprima, guarde, nem tome qualquer ação baseada >>> nessas informações. Notifique o >>> >>> remetente imediatamente por e-mail e apague a mensagem permanentemente. >>> Atenção: embora a Isimples >>> >>> Telecom, tome seus cuidados para garantir a ausência de vírus neste >>> e-mail, a empresa não se responsabiliza >>> >>> por quaisquer perdas ou danos decorrentes do uso da mensagem e seus >>> anexos. A segurança e ausência de >>> >>> erros na transmissão do e-mail não podem ser garantidas, já que as >>> informações podem ser interceptadas, >>> >>> corrompidas, perdidas, destruídas, atrasadas, chegarem incompletas, ou, >>> ainda, conter vírus. Recomendamos >>> >>> checar se o e-mail e seus anexos contém vírus, uma vez que nem a >>> Isimples Telecom ou o remetente se >>> >>> responsabilizam pela transmissão destes. >>> >>> >>> >>> ------------------------- >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >>> ------------------------- >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >> >> >> >> -- >> Alessandro de Souza Rocha >> Administrador de Redes e Sistemas >> FreeBSD-BR User #117 >> Long live FreeBSD >> >> Powered by .... >> >> (__) >> \\\'',) >> \/ \ ^ >> .\._/_) >> >> www.FreeBSD.org >> ------------------------- >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd