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
[FUG-BR] Fwd: Re: [Off-topic] pf não redireciona com route-to
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. Att. - 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
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
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
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
[FUG-BR] Squid Cache videos youtube FreeBSD
Ola Pessoal. Estou fazendo testes com o squid para um cache de videos do youtube, Montei um servidor com ubuntu e squid 3 e funcionou consegui fazer cache do youtube. Mas utilizando o FreeBSD 9.1 com a versão do squid do repositorio com as mesmas configurações não funciona. Alguém ja montou algo parecido, passou pelos mesmos problemas. Estou baixando a versão 10 para testar. 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
[FUG-BR] OpenBGPD com rota em outra rede
Ola pessoal, não sei se o assunto e off-topic, mas se for desconsiderem Estou configurando BGP utilizando FreeBSD e OpenBGPD. A sessão BGP fecha porém não navego. Fazendo uma analise com o pessoal da operadora verifiquei que o nexthop das rotas aprendidas via BGP apontam para o endereço dos 2 peer que fecho o BGP(multihop) dentro da rede da operadora, e não para o endereço IP conectado diretamente. Eu inicialmente crio uma rota estatica apontando para esses 2 peer BGP indo pelo roteador diretamente conectado. Mas quando o BGP fecha, todas as rotas apontam para esses 2 IPs dentro da nuvem da operadora, e não para o ip diretamente conectado ( e como se tivesse um gateway default em outra rede e uma rota estatica para chegar nesse gateway default). Tipo se um pacote vir para o destino 8.8.8.8 o qual na tabela de rotas aponta para o peer BGP ele vai ter q procurar de novo na tabela de rotas para chegar nesse gateway remoto(vai usar minha rota estatica), fazendo 2 consultas na tabela de roteamento, isso não gera overhead? E testei em um roteador Cisco com a operadora e funcionou o FreeBSD não vai. Alguem já passou por isso? Isso e normal do BGP ou tem haver de como o FreeBSD faz o lookup das rotas?. 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
Re: [FUG-BR] OpenBGPD com rota em outra rede
On 10/03/2013 10:08 AM, Luiz Otavio O Souza wrote: 2013/10/3 spiderslack spidersl...@yahoo.com.br: Ola pessoal, não sei se o assunto e off-topic, mas se for desconsiderem Estou configurando BGP utilizando FreeBSD e OpenBGPD. A sessão BGP fecha porém não navego. Fazendo uma analise com o pessoal da operadora verifiquei que o nexthop das rotas aprendidas via BGP apontam para o endereço dos 2 peer que fecho o BGP(multihop) dentro da rede da operadora, e não para o endereço IP conectado diretamente. Eu inicialmente crio uma rota estatica apontando para esses 2 peer BGP indo pelo roteador diretamente conectado. Mas quando o BGP fecha, todas as rotas apontam para esses 2 IPs dentro da nuvem da operadora, e não para o ip diretamente conectado ( e como se tivesse um gateway default em outra rede e uma rota estatica para chegar nesse gateway default). Tipo se um pacote vir para o destino 8.8.8.8 o qual na tabela de rotas aponta para o peer BGP ele vai ter q procurar de novo na tabela de rotas para chegar nesse gateway remoto(vai usar minha rota estatica), fazendo 2 consultas na tabela de roteamento, isso não gera overhead? E testei em um roteador Cisco com a operadora e funcionou o FreeBSD não vai. Alguem já passou por isso? Isso e normal do BGP ou tem haver de como o FreeBSD faz o lookup das rotas?. Desde já agradeço. Acho que é só você alterar o nexthop das rotas aprendidas, nao ? # adicione no seu bgpd.conf match from any set nexthop ip.do.seu.gateway.bgp E claro, você deve melhorar esse filtro e fazer ele ser mais especifico para a sua situação (mas pra um unico upstream ele esta ok...). Att., Luiz - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Funcionou perfeito fiz o match para cada peer, funcionando FreeBSD+CARP+OpenBGPD Obrigado Luiz. 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] configurar tunel ipv6 gif no freebsd
Renato, funcionou era o s plural. Sou novo no Free administrava servidores Linux. Desculpe a duvida tao banal e obrigado Att. On 09/03/2013 11:51 AM, Renato Botelho wrote: On 03-09-2013 12:37, spiderslack wrote: Pessoal, bom dia. Estou configurando um tunnel ipv6 no hurricane. Se eu digitar os comandos manualmente no promtp funciona. Mas queria configurar no rc.conf, abaixo segue a configuração que estou utilizando. ipv6_activate_all_interfaces=YES ifconfig_re1_ipv6=inet6 2001:470::b39::1 prefixlen 64 gif_interface=gif0 Aqui é no plural, gif_interfaces=gif0 gifconfig_gif0=xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy ifconfig_gif0_ipv6=inet6 2001:470:xxx:b39::2 prefixlen 64 #ifconfig_gif0_ipv6=inet6 2001:470:xxx:b39::2 ipv6_defaultrouter=2001:470:xxx:b39::1 rtadvd_enable=YES rtadvd_interfaces=re1 Alguma idéia de onde estou errando. Fora isso me parece tudo ok. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
