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

Quarta Novembro 5 15:20:09 BRST 2014

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 <listas em 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 <
> spiderslack em 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 > 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 0
>> 14:02:33.066233 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 50571944 ecr
>> 0,nop,wscale 7], length 0
>> 14:02:35.066212 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 50572144 ecr
>> 0,nop,wscale 7], length 0
>>
>> *varios SYNs**e o FIN do cliente.
>> *
>> 14:02:35.668516 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 [F.], seq
>> 112, ack 1, win 115, options [nop,nop,TS val 8949456 ecr 50571790], length 0
>> 14:02:35.668795 40:f2:e9:db:6b:23 > 00:00:5e:00:01:0f, 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.709782 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 2,
>> win 115, options [nop,nop,TS val 8949498 ecr 50572204], length 0
>>
>> *Captura na re0**- WAN
>> *
>> 14:02:32.070684 00:1a:3f:b1:58:0c > f8:72:ea:74:a1:b0, 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 0
>> 14:02:32.181013 f8:72:ea:74:a1:b0 > 00:00:5e:00:01:01, 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
>> *
>> **O three way handshake ocorre pela metade. So tenho o SYN e SYN/ACK. Ai
>> o cliente manda o R(reset).**
>> *
>> 14:02:32.182622 00:1a:3f:b1:58:0c > f8:72:ea:74:a1:b0, ethertype IPv4
>> (0x0800), length 54: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq
>> 299551138, win 0, length 0
>> *
>> **E o processo ocorre novamente varias vezes
>>
>> *14:02:33.066251 00:1a:3f:b1:58:0c > f8:72:ea:74:a1:b0, 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 50571944 ecr
>> 0,nop,wscale 7], length 0
>> 14:02:33.324277 f8:72:ea:74:a1:b0 > 00:00:5e:00:01:01, 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.325807 00:1a:3f:b1:58:0c > f8:72:ea:74:a1:b0, ethertype IPv4
>> (0x0800), length 54: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq
>> 299551138, win 0, length 0
>> 14:02:35.066237 00:1a:3f:b1:58:0c > f8:72:ea:74:a1:b0, 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 50572144 ecr
>> 0,nop,wscale 7], length 0
>> 14:02:35.215480 f8:72:ea:74:a1:b0 > 00:00:5e:00:01:01, 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.216632 00:1a:3f:b1:58:0c > f8:72:ea:74:a1:b0, ethertype IPv4
>> (0x0800), length 54: 200.2.2.2.24450 > 23.216.160.170.80: Flags [R], seq
>> 299551138, win 0, length 0
>>
>> 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
>>
>
>
> --
> [ ]'s
> Fabricio Lima
> When your hammer is C++, everything begins to look like a thumb.
>
>