@imortalis12 boa tarde.

Você conseguiu selecionar o problema?

@marcoafm olá, sim é possível permitir o acesso a internet/rede apenas com os macs autorizados, faça o seguinte processo:
Na interface de rede em DHCP, ative a opção "Allow known clients from only this interface", desse modo apenas os equipamentos que estiverem com o mac cadastrado pegarão IP, do contrário ficarão com o IP 169.XXX.XXX.XXX. Espero ter ajudado

resolvido aqui:
https://forum.netgate.com/topic/181618/when-updating-to-pfsense-2-7-ce-stunnel-ldap-google-does-not-work-use-in-captive-portal/

@Gloower ja tentou colocar esse site para passar diretamente pelo Squid sem fazer cache ?

@luanks01 said in configurar acesso remoto:

Tentei com e sem https e sem a porta também

Mostre como ficou a sua regra, pode ser que seu provedor não permita conexões na porta 443 de entrada, o que é muito comum em planos residenciais. Inclusive outras portas também são bloqueadas.

Caso esse seja o caso, tente alterar a sua porta dessa forma:

62b92a87-263b-4e08-910d-6bad7892887a-image.png

No campo TCP port, ponha uma porta alta qualquer, como por exemplo 4443, depois altere a regra que você criou anteriormente para permitir conexões na porta que você escolheu, no exemplo aqui desse post seria a 4443.

Lembrando que agora a gerência do firewall será nessa nova porta.

Isso geralmente é muito útil na criação de apresentações para o meu local de trabalho. Posso localizar qualquer fotografia e vídeo, mesmo os balao vetores. Estou muito agradecido pelas oportunidades e recursos atuais.

@tilinux0 O tópico é antigo, mas eu estava com o mesmo problema, pesquisei em tudo quanto é canto, mas não achei a solução, então resolvei pesquisar na fonte, o problema é a versão do SquidAnalyser, a versão disponível no pfSense é a 6.5 que tem problemas com os logs do E2Guardian 5.2 ou superior (https://github.com/darold/squidanalyzer) e não há ainda versão mais recente disponível para o pfSense, então eu substitui o arquivo /usr/local/lib/perl5/site_perl/SquidAnalyzer.pm pela versão 6.6 disponível no github e voilà. Pode ser necessário rodar o comando "squid-analyzer /var/log/e2guardian/access.log -r" manualmente pela linha de comando para rodar o primeiro relatório, mas funcionou para mim.

@Idriss-Satende cria uma regra no seu firewall permitindo o tráfego tcp/udp na porta 53 com o IP do seu AD. Sem essa regra o AD não vai ter permissão de pesquisa de DNS, logo não vai resolver nomes...

Começa verificando a pilha da placa mãe ou bateria do servidor. Se não for isso, provavelmente algum defeito nela também, não acredito que seja no firewall. Isso é quase com certeza problema no seu hardware.

Tente adicionar o endereço de firewall para aprovar a lista. Deveria ter uma lista fictícia que o IP entra nisso.

Exemplo:
Screenshot 2023-05-28 at 9.00.45 AM.png

Screenshot 2023-05-28 at 9.01.32 AM.png

Screenshot 2023-05-28 at 9.08.10 AM.png

@rodrigolmp Pessoal, agradeço imensamente a ajuda dos amigos. Consegui descobrir aqui, era apenas o VID da porta que eu não estava alterando para 4092. Um pequeno detalhe que me custou um bom tempo de trabalho, mas valeu o aprendizado.

Obrigado a todos

@faustovianna Você conseguiu a lista?

Rapaz... já estava desistindo de usar o Captive Portal. Após remover as regras de Traffic Shapper, funfou aqui! 😀

Habilitei os limites nas opções do próprio Captive!

Valeu pela informação... já salvou dois! 🤜 🤛

Valeu!!

qual a versão do pfsense???

O LOG STORE DIRECTORY: /var/squid/logs

Bom dia. Depois de algumas pesquisas encontrei a solução para o problema do whatsapp no pfsense 2.6. mais especificamente no captive portal. Para solucionar o problema basta instalar o Patch "Fix Captive Portal handling of non-TCP traffic after login". Segue link da solução:
https://forum.netgate.com/topic/170242/liga%C3%A7%C3%B5es-de-whatsapp-pelo-captive-portal-n%C3%A3o-funcionam

Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 4 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
pfSense-pkg-squid: 0.4.45_9
pfSense-pkg-squidGuard: 1.16.18_20
squid: 4.15
squidGuard: 1.4_15

Number of packages to be removed: 4

The operation will free 11 MiB.

Proceed with deinstalling packages? [y/N]:

@felipegilo https://docs.netgate.com/pfsense/en/latest/firewall/index.html

@mcury

Obrigado, deu certo !

Bom dia, pessoal!

Gostaria de compartilhar aqui uma manutenção que realizei neste sábado em nosso ambiente, com o intuito de solucionar o problema tratado neste post.

Realizamos um levantamento das regras e interfaces que poderíamos remover do Firewall > Rules > Floating. Antes de realizar a manutenção em si, realizei alguns testes e registrei os seguintes picos nos links:

Alteração de Firewall > Rules:
Link1 - 553,4ms
Link2 - 549,9ms
Link3 - 550,9ms

Modificação OpenVPN config:
Link1 - 776,0ms
Link2 - 777,7ms
Link3 - 776,7ms

Alteração System > Routing
Link1 - 1294,7ms
Link2 - 1292,2ms
Link3 - 1293,8ms

Após a manutenção e otimização das regras de floating e também a exclusão de algumas interfaces realizei novamente os mesmos testes e obtive os seguintes valores:

Alteração de Firewall > Rules:
Link1 - 220,3ms
Link2 - 216,8ms
Link3 - 230,5ms

Modificação OpenVPN config:
Link1 - 316,7ms
Link2 - 336,1ms
Link3 - 322,5ms

Alteração System > Routing
Link1 - 451,2ms
Link2 - 456,5ms
Link3 - 456,1ms

Mesmo tendo uma baixa na oscilação dos links o problema ainda persiste, mas acredito que através desta manutenção consegui tirar a prova que o problema está ligado diretamente a estas regras.

Agradeço qualquer ajuda possível,