@Ivart: Já descobri o problema, o patch não funciona no Squid3 somente na versão dev, já corrigi o squid.inc para aplicar o patch correto quando o pfsense for versão 2.1, o problema atual que não consegui achar solução em lugar nenhuma é relativo ao redirecionamento para o CP quando o proxy é fixado no browser do cliente ou na conexão wireless do mobile (IOS/Androis). No browser ainda é possivel colocar na mão o endereço do gateway :8000 para acessar o CP mas no Mobile uma vez configurada a conexão WiFi com o proxy não tem como o cliente fazer o login. Ainda não existe uma solução prática de integração entre o CP e o Squid. A unica coisa que consegui fazer com relação a isso é na parte de ignorar o proxy adicionar um site (por exemplo o de onde você trabalha) e o ip do pfsense, e no squid habilitar também a navegação http transparente, fazendo tudo isso após o usuario acessar o site especificado vai abrir a tela de login e autenticar para os outros sites, mas não achei isso muito pratico, estou procurando algo mais user…

@Bruno: @breno.uni: O problema é que o NAT que entra pela interface do ADSL não abre o meu TS. Se eu escolher em: System –> Routing -- Interface ADSL como Defautl o NAT funciona perfeitamente pelo ADSL e para o da Embratel. OU seja, meu NAT só funciona com o link escolhido como default. Caro Breno, geralmente isso ocorre quando voce desabilitar o replay-to (responsavel de marcar o pacote com o gateway de origem da interface). Caminho dessa configuração é "System > Advanced > Firewall and NAT > Firewall Advanced > Disable reply-to" (deve permanecer desabilitada). Se a opção estiver desabilitada, navegue até "Interfaces > ADSL > Static IPv4 configuration > IPv4 Upstream Gateway" e verifique se o gateway está definido. Creio que o comando abaixo vai mostrar os pacotes saindo pela interface (dyndns) com o IP da interface ADSL durante uma tentativa de acesso via RDP na interface ADSL. tcpdump -ni inter_dyndns port 3389 and src ip_int_adsl Verique essas configurações e post aqui. att, Bruno Pinheiro Não resolveu :(

Tenho praticamente o mesmo problema, porém eu acesso o WebGui do Pfsense com muitas dificuldades. Sempre que eu faço alguma alteração de Ip quanto na LAN quanto na WAN, o WEBGui fica totalmente lento, chegando a ficar uns 10 min para abri alguma pagina solicitada. Verificando com tpcdump parece estar tudo ok, não recebo erro nenhum. A placa de rede é nova, já troquei 3 vezes e o problema persiste. O acesso via SSH funciona perfeitamente, o ping para LAN também. Alguem tem ideia? Isso acontece em qualquer navegar de qualquer computador da rede. Verifique no dashboard a utilização da imagem abaixo: Se estiver sobre carregado, adicione a entrada abaixo no caminho "System > Advanced > System Tunables": Tunable Name: kern.ipc.nmbclusters Value: 262144 att, Bruno Pinheiro [image: dashboard.JPG]

Caro vlcunes, verifique o 6º post do tópico abaixo: https://forum.pfsense.org/index.php?topic=69380.0 desconsidere a parte sobre proxy transparente https e http, verifique somente a parte de firewall att, Bruno Pinheiro

teste esse. [RANGE YOUTUBE.txt](/public/imported_attachments/1/RANGE YOUTUBE.txt)

@Bruno: Então, minha sugestão foi você adicionar todas as VLANs no Debian e configurar o pool de cada vlan (transformando o debian em um "concentrador de DHCP"). Nesse ambiente supracitado, você não utilizaria o DHCP relay. A porta do Debian seria trunk (tagged). Veja se isso lhe atende, caso não post aqui, e vamos estudar juntos sobre a outra solução (relay dhcp do debian para as vlans das redes através do PFsense). abraços. att, Bruno Pinheiro Compreendi agora, no caso o único problema que teria em fazer isso é usar mais um IP de cada subrede para o DHCP (sendo que em alguns locais da empresa os técnicos colocam as impressoras com os IPs finais e .253, 252, etc e os computadores com os iniciais, .2, .3, etc. Porem realmente parece ser a opção mais simples de se fazer, obrigado pela dica. =)

O servidor DNS estava com o serviço parado….

Em custons do squid, adicione essas duas linhas no inicio: acl noauth src 192.168.200.100 192.168.200.101 http_access allow noauth Dessa forma ele não pedirá autenticação. Mas passará pelo proxy normalmente e poderá ser filtrado pelo squidguard através dos IPs. Quanto ao wpad, não esqueça que se for utiliza-lo com o tipo DHCP, o mesmo não tem suporte para o mozilla. E se for utilizar o wpad em DNS, as maquinas precisam estar no A.D. por causa do sufixo dns (ou você pode adicionar na mão esse sufixo. "nunca testei adicionando na mão, não sei informar se funciona"). att, Bruno Pinheiro

@marcelloc: Tente o mais simples, configure o etc/hosts do pfsense para responder o nome do servidor no ip interno. Olá Marcelo, Essa configuração que o colega Robson fez no DNS_Forward é justamente isso que você indicou. Quando adiciona-se uma entrada manual no DNS_Forward, esta é gravada diretamente no /etc/hosts. Se no terminal voce executar o comando cat /etc/hosts , verá que a entrada supracitada, consta no arquivo. Para testes, se eu permitir o nat + proxy, em Firewall / NAT, funciona, mas não sei se essa é a forma correta Caro Robson, o nat + proxy é sim uma das soluções, mas eu recomendo fazer uso de um servidor DNS para isso (se possível dedicado) encontrei muitas informações sobre performance do proxy a respeito disso. Em fim, faça o seguinte teste em seu cliente e servidor e verifique se ambos respondem o IP interno. Cliente: ping intranet.dom.com.br Pfsense: ping intranet.dom.com.br Verifique também a ordem de consulta do pfsense: cat /etc/resolv.conf a saída deste comando deve ser mais ou menos assim domain domain.local nameserver 127.0.0.1 nameserver X.X.X.X Verifique também em "Services > DNS Forwarder > Interfaces" se a interface Localhost está marcada para ouvir requisições. Agora não lembro se quando utiliza-se proxy transparente, ele resolve o dns a partir do cliente para chegar no gateway e ao chegar no proxy ele faz uso da mesma resolução ou se ao chegar no proxy, o proxy faz uma nova requisição dns para o domínio solicitado. Vou ler a respeito, aguardamos suas respostas att, Bruno Pinheiro.

Ola estou com um problema com face aqui também, fiz bloqueio por esses mesmos endereços na alias, mas mesmo assim esta passando, mas sinceramente eu não cheguei a reiniciar. Verifique essas questões no meu ultimo post do tópico abaixo, caso você faça uso de um proxy server. https://forum.pfsense.org/index.php?topic=69380.msg435393#msg435393 att, Bruno Pinheiro

Roger, boa noite! De que forma você está tentando acesso (Ex: WEB, VPN, ssh)? Enquanto ao local de acesso, quando você não consegui, dar algum erro? Será que na rede você origina o acesso está bloqueada. Da rede bloqueada faz o seguinte teste: "telnet ipdestino: porta de acesso" e veja se dar erro. Se possivel, detalhe mais…

Pessoal consegui resolver.. Alterei a regra em firewall -> NAT -> portforward Porém alterei no final da regra em "filter rule association" para "pass" antes estava "add associated filter rule", em outro firewall que tenho está assim, e funciona. Desta forma não foi criado a regra em firewall -> rules -> WAN que associa o NAT. Queria saber se tem algum problema deixar "PASS" em "filter rule association"? [image: 1.JPG] [image: 1.JPG_thumb] [image: 2.JPG] [image: 2.JPG_thumb]

Mesmo problema aqui se eu configuro a proxy da bypas no captive to usando o squid3-dev 3.3.10 pkg 2.2.6