Eu já encontrei o problema era a máquina com o serviço de ftp que estava com o default gateway errado. Mas já testei e não funciona rdr PASS. até há algum tempo havíamos discutido isso na lista.
obrigado a todos! Em 26/06/07, Thiago J. Ruiz<[EMAIL PROTECTED]> escreveu: > experimenta > > rdr pass on ..... > > gera mantem o estado automaticamente liberando a inda e a vinda da conexao > > > (Se eu estiver falando groselha me corrijam), mas pra mim funciona em > vários servidores. > > abraço > > Em 26/06/07, Lutieri G.<[EMAIL PROTECTED]> escreveu: > > To montando um firewall e está assim: > > > > srv# pfctl -sn > > No ALTQ support in kernel > > ALTQ related functions disabled > > nat pass on em1 inet all -> 201.xx.xx.161 > > rdr on em1 inet proto tcp from any to 201.xx.xx.161 port = ftp -> > > 172.16.4.2 port 21 > > srv# > > > > > > srv# pfctl -sr > > No ALTQ support in kernel > > ALTQ related functions disabled > > pass in all keep state > > pass out all keep state > > pass in on em0 inet proto tcp from <acessolocal> to 172.16.4.240 port > > = ssh keep state > > srv# > > > > Empaquei aqui. Olha a situação: > > > > > > eu estou na máquina 201.xx.x.5(uma máquina na internet) tentando > > acessar o firewall(201.xx.xx.161) que deveria redirecionar a conexao > > ftp para 172.16.4.2. > > > > Não vai de jeito nenhum ... cheguei a liberar tudo pra ver se funciona e > > nada. > > Li nos histórico da lista mas não encontrei a solução, não pro meu caso. > > > > O mais interessantes é que as regras estão passado pelos filtros. Pois > > quando eu vou na estação quem tá rodando o ftp(172.16.4.2) e rodo o > > tcpdump eu vejo pacotes vindos do IP remoto de onde eu tento acessar. > > > > local# tcpdump -n host 201.xx.x.5 > > > > 13:52:13.368172 IP 172.16.4.2.21 > 201.xx.x.5.51007: S > > 1550150509:1550150509(0) ack 2596759555 win 5792 <mss > > 1460,sackOK,timestamp 10779497[|tcp]> > > > > 13:52:16.348249 IP 172.16.4.2.21 > 201.xx.x.5.51007: S > > 1550150509:1550150509(0) ack 2596759555 win 5792 <mss > > 1460,sackOK,timestamp 10779795[|tcp]> > > > > 13:52:17.361694 IP 172.16.4.2.21 > 201.xx.x.5.51007: S > > 1550150509:1550150509(0) ack 2596759555 win 5792 <mss > > 1460,sackOK,timestamp 10779897[|tcp]> > > > > 13:52:23.361246 IP 172.16.4.2.21 > 201.xx.x.5.51007: S > > 1550150509:1550150509(0) ack 2596759555 win 5792 <mss > > 1460,sackOK,timestamp 10780497[|tcp]> > > > > 13:52:35.560319 IP 172.16.4.2.21 > 201.xx.x.5.51007: S > > 1550150509:1550150509(0) ack 2596759555 win 5792 <mss > > 1460,sackOK,timestamp 10781717[|tcp]> > > > > 13:52:59.558496 IP 172.16.4.2.21 > 201.xx.x.5.51007: S > > 1550150509:1550150509(0) ack 2596759555 win 5792 <mss > > 1460,sackOK,timestamp 10784117[|tcp]> > > > > > > Porém me parece, talvez eu esteja errado(tomara que sim), que a > > estação 172.16.4.2 está enviando pacotes SYN para a máquina remota > > 201.xx.x.5. e mais estranho que eu num vejo os pacotes vindo da > > máquina externa só indo para ela. > > > > Alguma sugestão? > > > > É incrível mas tem meia dúzia de linhas e não funciona... por favor se > > alguém puder ajudar fico grato. > > > > -- > > Att. > > Lutieri G. B. > > ------------------------- > > Histórico: http://www.fug.com.br/historico/html/freebsd/ > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > > -- > Thiago J. Ruiz > http://thiagoruiz.blogspot.com > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Att. Lutieri G. B. ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
