Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[Renato Botelho]

> On Nov 6, 2014, at 16:05, spiderslack  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

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[Renato Botelho]

> On Nov 6, 2014, at 10:36, spiderslack  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

[spiderslack]

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

[Renato Botelho]

> On Nov 5, 2014, at 14:10, spiderslack  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

[Alessandro de Souza Rocha]

Em 5 de novembro de 2014 16:51, spiderslack  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

[spiderslack]

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

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[Fabricio Lima]

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 
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

[spiderslack]

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

[EnioRM]

2014-11-05 14:10 GMT-02:00 spiderslack :

> 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 *
*Não perca suas anotações. Use o Evernote
*
-
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

[spiderslack]

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

[Fabricio Lima]

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 
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 89

Re: [FUG-BR] [Off-topic] pf não redireciona com route-to

[Fabricio Lima]

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

[FUG-BR] [Off-topic] pf não redireciona com route-to

[spiderslack]

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 5057184