Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
Em 5 de novembro de 2014 16:51, spiderslack spidersl...@yahoo.com.br escreveu: Em 11/05/2014 03:10 PM, EnioRM escreveu: Senhores! apenas por curiosidade: spiderslack, como está os options do seu pf.conf set state-policy if-bound ou floating (que é o default)? att Ola Enio Ja tentei as duas opções mas esta como default atualmente. Att. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Bom dia a todos, meu exemplo. rdr on $ext_if1 proto tcp from any to any port 25255 - 200.0.0.1 rdr on $ext_if1 proto tcp from any to any port 21 - 200.0.0.1 rdr on $ext_if1 proto tcp from any to any port 20 - 200.0.0.1 rdr on $ext_if1 proto tcp from any to any port 48000 - 200.0.0.1 rdr on $ext_if1 proto tcp from any to any port 49005 - 200.0.0.1 rdr on $ext_if1 proto tcp from any to any port 6900 - 200.0.0.6 rdr on $ext_if1 proto tcp from any to any port 5900 - 200.0.0.90 rdr on $ext_if1 proto tcp from any to any port 5800 - 200.0.0.139 rdr on $ext_if1 proto tcp from any to any port 3389 - 200.0.0.66 rdr on $ext_if1 proto tcp from any to any port 5901 - 200.0.0.17 rdr on $ext_if1 proto tcp from any to any port 49006 - 200.0.0.1 rdr on $ext_if1 proto tcp from any to any port 35999 - 200.0.0.20 rdr on $ext_if1 proto tcp from any to any port 35000 - 200.0.0.20 -- 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
Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
On Nov 5, 2014, at 14:10, spiderslack spidersl...@yahoo.com.br wrote: Ola pessoal. Se o assunto for off-topic me desculpe. Por nao se tratar especificamente de FreeBSD. Mas axo já tentei de tudo. Estou tentando fazer um redirecionamento de porta 80 para um proxy. Tenho um FreeBSD com 3 interfaces. 1 re0 - wan 2 re1 - lan 3 alc0 - rede do proxy Todas as interfaces são ips válidos não tenho nat nesse FreeBSD. O endereço IP do proxy é 200.1.1.1(IP exemplo) pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from any to any port 80 pass in quick on re0 route-to (alc0 200.1.1.1) proto tcp from any port 80 to any Vou fazer umas perguntas, mais pra entender o seu cenário e tentar entender o que tá dando errado. 1. O seu proxy roda em um equipamento separado de onde roda o firewall, certo? 2. Se a resposta da #1 for sim, em qual rede ele está? na alc0? 3. O seu proxy atende na porta 80? 4. Você quer que todas as conexões vindas da re1, com destino a qualquer host na porta 80 seja redirecionado para o proxy, correto? []s -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
Bom dia Renato Vou fazer umas perguntas, mais pra entender o seu cenário e tentar entender o que tá dando errado. 1. O seu proxy roda em um equipamento separado de onde roda o firewall, certo? Sim, mara cache 2. Se a resposta da #1 for sim, em qual rede ele está? na alc0? digamos que a rede seja 201.2.2.0/24. E uma rede válida. 3. O seu proxy atende na porta 80? Segundo o suporte mara cache sim 4. Você quer que todas as conexões vindas da re1, com destino a qualquer host na porta 80 seja redirecionado para o proxy, correto? Sim correto. Nesse firewall não tenho NAT somente roteamento. Tanto a LAN como a WAN são ips válidos. Att. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
On Nov 6, 2014, at 10:36, spiderslack spidersl...@yahoo.com.br wrote: Bom dia Renato Vou fazer umas perguntas, mais pra entender o seu cenário e tentar entender o que tá dando errado. 1. O seu proxy roda em um equipamento separado de onde roda o firewall, certo? Sim, mara cache 2. Se a resposta da #1 for sim, em qual rede ele está? na alc0? digamos que a rede seja 201.2.2.0/24. E uma rede válida. 3. O seu proxy atende na porta 80? Segundo o suporte mara cache sim 4. Você quer que todas as conexões vindas da re1, com destino a qualquer host na porta 80 seja redirecionado para o proxy, correto? Sim correto. Nesse firewall não tenho NAT somente roteamento. Tanto a LAN como a WAN são ips válidos. Certo, então na minha opinião você deveria usar uma regra de rdr pra fazer esse redirect, e tem que lembrar de negar o IP do proxy, seria algo mais ou menos assim: rdr pass on re1 inet proto tcp from re1:network to ! IP_DO_PROXY port 80 - IP_DO_PROXY port 80 -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
On Nov 6, 2014, at 16:05, spiderslack spidersl...@yahoo.com.br wrote: Certo, então na minha opinião você deveria usar uma regra de rdr pra fazer esse redirect, e tem que lembrar de negar o IP do proxy, seria algo mais ou menos assim: rdr pass on re1 inet proto tcp from re1:network to ! IP_DO_PROXY port 80 - IP_DO_PROXY port 80 -- Obrigado por responder Renato, Mas não funciona o redirecioamento até funciona,porém ele muda o destino do pacote vai com destino ao mara cache e nao ao site o site vai no header htttp Eu acho que descobri a razão do problema, mas e apenas uma teoria. Imaginemos que um cliente faz um request na porta 80 com destino ao google O mara cache fica em modo transparente ou seja como o modulo tproxy funciona, Quando o request passa pelo meu freebsd com destino ao google e porta de destino a 80 ele usa o route-to redireciona para o mara cache porque o destino do pacote NÃO está diretamente conectado. O mara cache faz o spoofing do ip do google e fecha o three way handshake com o cliente. A partir dai o Mara cache não possuir o objeto em cache abre uma nova conexão para o google para buscar este objeto. O mara cache envia um SYN para o google com origem no ip do cliente não no seu proprio IP(isso para quando o pacote voltar com destino ao cliente e não ter um unico ip acessando a internet) O google responde com um SYN/ACK para o ip cliente spoofado pelo mara cache. Quando esse SYN/ACK chega no freeBSD ele possue a regra para o retorno devolver ao mara cache conforme abaixo. pass in log quick on re0route-to (alc0 200.1.1.1) proto tcp from any port 80 to $rede_lan A minha teoria e aqui meu freebsd esta diretamente conectado ao cliente então nao usa o route-to, o route-to somente seria usado para destino não diretamente conectado(estou preparando um ambiente para testar isso, assim que tiver resposta retorno) e o pacote SYN/ACK chega ao cliente(chega porque monitorei via tcpdump). E o cliente recebe um pacote fora de contexto/ordem tipo ele anteriormente fechou o three way handshake com o google spoofado pelo mara cache e ai chega outro SYN/ACK ai ele Reseta a conexão. Tudo que eu descrevi acima eu constatei olhando os logs do tcpdump. E na interface onde esta o proxy mara cache vejo varios pacotes SYN saindo e os SYN/ACK indo direto para o cliente. Nao uso o rdr porque não tenho nat nesse freebsd somente ip's válidos. Se alguém tiver alguma dica ou passou por algo parecido desde já agradeço. Não tinha me ligado que vc tava usando TPROXY, falha minha. Essa fico devendo pq nunca pus a mão. -- Renato Botelho - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] [Off-topic] pf não redireciona com route-to
Ola pessoal. Se o assunto for off-topic me desculpe. Por nao se tratar especificamente de FreeBSD. Mas axo já tentei de tudo. Estou tentando fazer um redirecionamento de porta 80 para um proxy. Tenho um FreeBSD com 3 interfaces. 1 re0 - wan 2 re1 - lan 3 alc0 - rede do proxy Todas as interfaces são ips válidos não tenho nat nesse FreeBSD. O endereço IP do proxy é 200.1.1.1(IP exemplo) pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from any to any port 80 pass in quick on re0 route-to (alc0 200.1.1.1) proto tcp from any port 80 to any A ida e volta porem notei via tcpdump a volta nao é redirecionada (fiz testes tentando acessar o site da Cisco: 23.216.160.170): * **captura na re1**- LAN* 14:02:31.529558 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 74: 200.2.2.2.59297 23.216.160.170.80: Flags [S], seq 2881852864, win 14600, options [mss 1460,sackOK,TS val 8945318 ecr 0,nop,wscale 7], length 0 14:02:31.529733 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.59297: Flags [S.], seq 2813051021, ack 2881852865, win 28960, options [mss 1460,sackOK,TS val 50571790 ecr 8945318,nop,wscale 7], length 0 14:02:31.533785 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 66: 200.2.2.2.59297 23.216.160.170.80: Flags [.], ack 1, win 115, options [nop,nop,TS val 8945322 ecr 50571790], length 0 *Three way handshake feito* 14:02:32.181023 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.24450: Flags [S.], seq 1894693316, ack 299551138, win 14480, options [mss 1460,sackOK,TS val 2263835919 ecr 50571844,nop,wscale 5], length 0 14:02:32.182614 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 60: 200.2.2.2.24450 23.216.160.170.80: Flags [R], seq 299551138, win 0, length 0 * **Quando o site da cisco responde com SYN/ACK o cliente responde com um Reset, ou seja não esta encaminhando a volta para o proxy minha regra de volta não esta funcionando**. O que não entendo porque o cliente envia o RST. Sera que ele considera uma nova conexão? e como nao tem three way handshake feito ele reseta? E o processo ocorre algumas vezes enquanto o cliente tenta*. 14:02:33.324284 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.24450: Flags [S.], seq 1910248059, ack 299551138, win 14480, options [mss 1460,sackOK,TS val 2263836914 ecr 50571944,nop,wscale 5], length 0 14:02:33.325800 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 60: 200.2.2.2.24450 23.216.160.170.80: Flags [R], seq 299551138, win 0, length 0 14:02:35.215487 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.24450: Flags [S.], seq 28856710, ack 299551138, win 14480, options [mss 1460,sackOK,TS val 2227668864 ecr 50572144,nop,wscale 5], length 0 14:02:35.216626 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 60: 200.2.2.2.24450 23.216.160.170.80: Flags [R], seq 299551138, win 0, length 0 14:02:35.668511 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 66: 200.2.2.2.59297 23.216.160.170.80: Flags [F.], seq 112, ack 1, win 115, options [nop,nop,TS val 8949456 ecr 50571790], length 0 14:02:35.668802 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 66: 23.216.160.170.80 200.2.2.2.59297: Flags [F.], seq 1, ack 113, win 227, options [nop,nop,TS val 50572204 ecr 8949456], length 0 14:02:35.709774 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 66: 200.2.2.2.59297 23.216.160.170.80: Flags [.], ack 2, win 115, options [nop,nop,TS val 8949498 ecr 50572204], length 0 *captura na alc0**- Interface onde o proxy esta conectado * 14:02:31.529573 00:1a:3f:b1:51:05 40:f2:e9:db:6b:23, ethertype IPv4 (0x0800), length 74: 200.2.2.2.59297 23.216.160.170.80: Flags [S], seq 2881852864, win 14600, options [mss 1460,sackOK,TS val 8945318 ecr 0,nop,wscale 7], length 0 14:02:31.529726 40:f2:e9:db:6b:23 00:00:5e:00:01:0f, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.59297: Flags [S.], seq 2813051021, ack 2881852865, win 28960, options [mss 1460,sackOK,TS val 50571790 ecr 8945318,nop,wscale 7], length 0 14:02:31.533789 00:1a:3f:b1:51:05 40:f2:e9:db:6b:23, ethertype IPv4 (0x0800), length 66: 200.2.2.2.59297 23.216.160.170.80: Flags [.], ack 1, win 115, options [nop,nop,TS val 8945322 ecr 50571790], length 0 *Three way handshake feito** **Aqui noto que o proxy tenta sair creio que ele abre 2 conexão uma para o cliente outra para o server tipo como o modulo tproxy do linux/squid faz.** * 14:02:32.070663 40:f2:e9:db:6b:23 00:00:5e:00:01:0f, ethertype IPv4 (0x0800), length 74: 200.2.2.2.24450 23.216.160.170.80: Flags [S], seq 299551137, win 29200, options [mss 1460,sackOK,TS val 50571844 ecr 0,nop,wscale 7], length
Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
Um tiro no escuro... Mas não uso regras assim com any any em proxy transparente... Sao perigosas... Vamos travar sua origem da regra q intercepta as requisições pra jogar no proxy. Faz algo tipo: Pass from $lan_NET to any 80 Tenta fazer isso no outro redirect tb. Ou vê se um só resolve. Tenta migrar pra ipfw e vê se o bug se apresenta Vou ler seu tcpdump antes de falar o proximo teste Fabricio Em quarta-feira, 5 de novembro de 2014, spiderslack spidersl...@yahoo.com.br escreveu: Ola pessoal. Se o assunto for off-topic me desculpe. Por nao se tratar especificamente de FreeBSD. Mas axo já tentei de tudo. Estou tentando fazer um redirecionamento de porta 80 para um proxy. Tenho um FreeBSD com 3 interfaces. 1 re0 - wan 2 re1 - lan 3 alc0 - rede do proxy Todas as interfaces são ips válidos não tenho nat nesse FreeBSD. O endereço IP do proxy é 200.1.1.1(IP exemplo) pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from any to any port 80 pass in quick on re0 route-to (alc0 200.1.1.1) proto tcp from any port 80 to any A ida e volta porem notei via tcpdump a volta nao é redirecionada (fiz testes tentando acessar o site da Cisco: 23.216.160.170): * **captura na re1**- LAN* 14:02:31.529558 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 74: 200.2.2.2.59297 23.216.160.170.80: Flags [S], seq 2881852864, win 14600, options [mss 1460,sackOK,TS val 8945318 ecr 0,nop,wscale 7], length 0 14:02:31.529733 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.59297: Flags [S.], seq 2813051021, ack 2881852865, win 28960, options [mss 1460,sackOK,TS val 50571790 ecr 8945318,nop,wscale 7], length 0 14:02:31.533785 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 66: 200.2.2.2.59297 23.216.160.170.80: Flags [.], ack 1, win 115, options [nop,nop,TS val 8945322 ecr 50571790], length 0 *Three way handshake feito* 14:02:32.181023 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.24450: Flags [S.], seq 1894693316, ack 299551138, win 14480, options [mss 1460,sackOK,TS val 2263835919 ecr 50571844,nop,wscale 5], length 0 14:02:32.182614 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 60: 200.2.2.2.24450 23.216.160.170.80: Flags [R], seq 299551138, win 0, length 0 * **Quando o site da cisco responde com SYN/ACK o cliente responde com um Reset, ou seja não esta encaminhando a volta para o proxy minha regra de volta não esta funcionando**. O que não entendo porque o cliente envia o RST. Sera que ele considera uma nova conexão? e como nao tem three way handshake feito ele reseta? E o processo ocorre algumas vezes enquanto o cliente tenta*. 14:02:33.324284 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.24450: Flags [S.], seq 1910248059, ack 299551138, win 14480, options [mss 1460,sackOK,TS val 2263836914 ecr 50571944,nop,wscale 5], length 0 14:02:33.325800 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 60: 200.2.2.2.24450 23.216.160.170.80: Flags [R], seq 299551138, win 0, length 0 14:02:35.215487 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.24450: Flags [S.], seq 28856710, ack 299551138, win 14480, options [mss 1460,sackOK,TS val 2227668864 ecr 50572144,nop,wscale 5], length 0 14:02:35.216626 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 60: 200.2.2.2.24450 23.216.160.170.80: Flags [R], seq 299551138, win 0, length 0 14:02:35.668511 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 66: 200.2.2.2.59297 23.216.160.170.80: Flags [F.], seq 112, ack 1, win 115, options [nop,nop,TS val 8949456 ecr 50571790], length 0 14:02:35.668802 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 66: 23.216.160.170.80 200.2.2.2.59297: Flags [F.], seq 1, ack 113, win 227, options [nop,nop,TS val 50572204 ecr 8949456], length 0 14:02:35.709774 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 66: 200.2.2.2.59297 23.216.160.170.80: Flags [.], ack 2, win 115, options [nop,nop,TS val 8949498 ecr 50572204], length 0 *captura na alc0**- Interface onde o proxy esta conectado * 14:02:31.529573 00:1a:3f:b1:51:05 40:f2:e9:db:6b:23, ethertype IPv4 (0x0800), length 74: 200.2.2.2.59297 23.216.160.170.80: Flags [S], seq 2881852864, win 14600, options [mss 1460,sackOK,TS val 8945318 ecr 0,nop,wscale 7], length 0 14:02:31.529726 40:f2:e9:db:6b:23 00:00:5e:00:01:0f, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.59297: Flags [S.], seq 2813051021, ack 2881852865, win 28960, options [mss 1460,sackOK,TS val 50571790 ecr 8945318,nop,wscale 7], length 0 14:02:31.533789 00:1a:3f:b1:51:05 40:f2:e9:db:6b:23, ethertype IPv4 (0x0800), length 66: 200.2.2.2.59297
Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
Repensando... voce NAO precisa do 2o redirect... quando um usuario na lan faz a requisiçao pra web, voce joga pro proxy. ele agora vai receber, processar, e matar esta conexao ele irá gerar uma nova conexao, a partir do IP dele, pra web... e o fw vai rotear certinho. Se voce bota um redirect nesta volta, pode induzir o reset. Ou seja, use APENAS um redirect, e como meu email anterior, TRAVANDO a origem: pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from $LOCAL_LAN to any port 80 isso jogará pro proxy e ele trata o resto, e devolve pra estação. [ ]'s Fabricio Lima When your hammer is C++, everything begins to look like a thumb. Em 5 de novembro de 2014 14:27, Fabricio Lima lis...@fabriciolima.com.br escreveu: Um tiro no escuro... Mas não uso regras assim com any any em proxy transparente... Sao perigosas... Vamos travar sua origem da regra q intercepta as requisições pra jogar no proxy. Faz algo tipo: Pass from $lan_NET to any 80 Tenta fazer isso no outro redirect tb. Ou vê se um só resolve. Tenta migrar pra ipfw e vê se o bug se apresenta Vou ler seu tcpdump antes de falar o proximo teste Fabricio Em quarta-feira, 5 de novembro de 2014, spiderslack spidersl...@yahoo.com.br escreveu: Ola pessoal. Se o assunto for off-topic me desculpe. Por nao se tratar especificamente de FreeBSD. Mas axo já tentei de tudo. Estou tentando fazer um redirecionamento de porta 80 para um proxy. Tenho um FreeBSD com 3 interfaces. 1 re0 - wan 2 re1 - lan 3 alc0 - rede do proxy Todas as interfaces são ips válidos não tenho nat nesse FreeBSD. O endereço IP do proxy é 200.1.1.1(IP exemplo) pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from any to any port 80 pass in quick on re0 route-to (alc0 200.1.1.1) proto tcp from any port 80 to any A ida e volta porem notei via tcpdump a volta nao é redirecionada (fiz testes tentando acessar o site da Cisco: 23.216.160.170): * **captura na re1**- LAN* 14:02:31.529558 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 74: 200.2.2.2.59297 23.216.160.170.80: Flags [S], seq 2881852864, win 14600, options [mss 1460,sackOK,TS val 8945318 ecr 0,nop,wscale 7], length 0 14:02:31.529733 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.59297: Flags [S.], seq 2813051021, ack 2881852865, win 28960, options [mss 1460,sackOK,TS val 50571790 ecr 8945318,nop,wscale 7], length 0 14:02:31.533785 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 66: 200.2.2.2.59297 23.216.160.170.80: Flags [.], ack 1, win 115, options [nop,nop,TS val 8945322 ecr 50571790], length 0 *Three way handshake feito* 14:02:32.181023 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.24450: Flags [S.], seq 1894693316, ack 299551138, win 14480, options [mss 1460,sackOK,TS val 2263835919 ecr 50571844,nop,wscale 5], length 0 14:02:32.182614 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 60: 200.2.2.2.24450 23.216.160.170.80: Flags [R], seq 299551138, win 0, length 0 * **Quando o site da cisco responde com SYN/ACK o cliente responde com um Reset, ou seja não esta encaminhando a volta para o proxy minha regra de volta não esta funcionando**. O que não entendo porque o cliente envia o RST. Sera que ele considera uma nova conexão? e como nao tem three way handshake feito ele reseta? E o processo ocorre algumas vezes enquanto o cliente tenta*. 14:02:33.324284 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.24450: Flags [S.], seq 1910248059, ack 299551138, win 14480, options [mss 1460,sackOK,TS val 2263836914 ecr 50571944,nop,wscale 5], length 0 14:02:33.325800 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 60: 200.2.2.2.24450 23.216.160.170.80: Flags [R], seq 299551138, win 0, length 0 14:02:35.215487 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 74: 23.216.160.170.80 200.2.2.2.24450: Flags [S.], seq 28856710, ack 299551138, win 14480, options [mss 1460,sackOK,TS val 2227668864 ecr 50572144,nop,wscale 5], length 0 14:02:35.216626 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 60: 200.2.2.2.24450 23.216.160.170.80: Flags [R], seq 299551138, win 0, length 0 14:02:35.668511 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 66: 200.2.2.2.59297 23.216.160.170.80: Flags [F.], seq 112, ack 1, win 115, options [nop,nop,TS val 8949456 ecr 50571790], length 0 14:02:35.668802 00:1a:3f:b1:51:05 00:22:57:64:08:c5, ethertype IPv4 (0x0800), length 66: 23.216.160.170.80 200.2.2.2.59297: Flags [F.], seq 1, ack 113, win 227, options [nop,nop,TS val 50572204 ecr 8949456], length 0 14:02:35.709774 00:22:57:64:08:c5 00:00:5e:00:01:0c, ethertype IPv4 (0x0800), length 66: 200.2.2.2.59297 23.216.160.170.80: Flags [.], ack 2,
Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
Em 11/05/2014 01:27 PM, Fabricio Lima escreveu: Um tiro no escuro... Mas não uso regras assim com any any em proxy transparente... Sao perigosas... Vamos travar sua origem da regra q intercepta as requisições pra jogar no proxy. Faz algo tipo: Pass from $lan_NET to any 80 Obrigado por responder Fabricio, Mas o any any foi somente para teste o ultimo teste que fiz, na verdade estou redirecionando somente meu ip para não parar o resto da rede Tenta fazer isso no outro redirect tb. Ou vê se um só resolve. Não resolveu Tenta migrar pra ipfw e vê se o bug se apresenta hum ipfw?! nunca trabalhei com ele, vou pesquisar e ver como se comporta. Vou ler seu tcpdump antes de falar o proximo teste Ok, obrigado . - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
2014-11-05 14:10 GMT-02:00 spiderslack spidersl...@yahoo.com.br: Ola pessoal. Se o assunto for off-topic me desculpe. Por nao se tratar especificamente de FreeBSD. Mas axo já tentei de tudo. Estou tentando fazer um redirecionamento de porta 80 para um proxy. Tenho um FreeBSD com 3 interfaces. 1 re0 - wan 2 re1 - lan 3 alc0 - rede do proxy Todas as interfaces são ips válidos não tenho nat nesse FreeBSD. O endereço IP do proxy é 200.1.1.1(IP exemplo) pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from any to any port 80 pass in quick on re0 route-to (alc0 200.1.1.1) proto tcp from any port 80 to any A ida e volta porem notei via tcpdump a volta nao é redirecionada (fiz testes tentando acessar o site da Cisco: 23.216.160.170): Desculpe pelo e-mail longo. Mas ja tentei de tudo. Tentei ao invés de route-to o reply-to sem sucesso tentei o divert-to tentei o rdr tambem sem sucesso o problema do RDR ele manda direto com destino ao proxy na verdade o destino e o site da cisco. Se alguem já passou por isso. Algum palpite que possa me ajuda desde já agradeço. Att. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Senhores! apenas por curiosidade: spiderslack, como está os options do seu pf.conf set state-policy if-bound ou floating (que é o default)? att -- *[]'* *EnioRM * *B**ackup na nuvem **com o Dropbox http://db.tt/VfwUj00m* *Não perca suas anotações. Use o Evernote https://www.evernote.com/referral/Registration.action?uid=51621327sig=309c50439fa60945a84ebe86b0f542f9* - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
Em 11/05/2014 02:20 PM, Fabricio Lima escreveu: Repensando... voce NAO precisa do 2o redirect... quando um usuario na lan faz a requisiçao pra web, voce joga pro proxy. ele agora vai receber, processar, e matar esta conexao ele irá gerar uma nova conexao, a partir do IP dele, pra web... Então segundo o suporte do proxy, ele não faz assim sai do proxy spoofado com meu ip(200.2.2.3 por exemplo), porque quando voltar, o pacote retorna em direção ao cliente ai preciso interceptar e jogar para o proxy.(isso para não sair com um único somente). O proxy é o mara cache. e o fw vai rotear certinho. Se voce bota um redirect nesta volta, pode induzir o reset. Com o redirect ou sem o reset acontece Ou seja, use APENAS um redirect, e como meu email anterior, TRAVANDO a origem: pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from $LOCAL_LAN to any port 80 isso jogará pro proxy e ele trata o resto, e devolve pra estação. Estou estudando como o ipfw funciona para ver se é possivel fazer isso. Att. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
ipfw: # Ativando Transparent Proxy ipfw add fwd 200.1.1.1,8080 tcp from 192.168.0.0/16 to any 80 ainda nao acreditei 100% de q seu proxy precisa spoofar algo tipo o websense com port mirror. fluxo segue assim: user1 pede a pagina www.uol.com.br:80 ao sair pelo fw1, ele redireciona pro proxy o proxy recebe a conexao from user1, destino uol (um socket aberto aqui, apos 3 way handshake) ele inicia uma NOVA conexao para uol, usando como origem o IP dele.. (proxy) ao receber de volta a pagina, ele devolve pela conexao com o usuario q ainda estava aberta o socket (repara q nao houve o 2o redirect) [ ]'s Fabricio Lima When your hammer is C++, everything begins to look like a thumb. Em 5 de novembro de 2014 16:12, spiderslack spidersl...@yahoo.com.br escreveu: Em 11/05/2014 02:20 PM, Fabricio Lima escreveu: Repensando... voce NAO precisa do 2o redirect... quando um usuario na lan faz a requisiçao pra web, voce joga pro proxy. ele agora vai receber, processar, e matar esta conexao ele irá gerar uma nova conexao, a partir do IP dele, pra web... Então segundo o suporte do proxy, ele não faz assim sai do proxy spoofado com meu ip(200.2.2.3 por exemplo), porque quando voltar, o pacote retorna em direção ao cliente ai preciso interceptar e jogar para o proxy.(isso para não sair com um único somente). O proxy é o mara cache. e o fw vai rotear certinho. Se voce bota um redirect nesta volta, pode induzir o reset. Com o redirect ou sem o reset acontece Ou seja, use APENAS um redirect, e como meu email anterior, TRAVANDO a origem: pass in quick on re1 route-to (alc0 200.1.1.1) proto tcp from $LOCAL_LAN to any port 80 isso jogará pro proxy e ele trata o resto, e devolve pra estação. Estou estudando como o ipfw funciona para ver se é possivel fazer isso. Att. - 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
Re: [FUG-BR] [Off-topic] pf não redireciona com route-to
Em 11/05/2014 03:10 PM, EnioRM escreveu: Senhores! apenas por curiosidade: spiderslack, como está os options do seu pf.conf set state-policy if-bound ou floating (que é o default)? att Ola Enio Ja tentei as duas opções mas esta como default atualmente. Att. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
