CAPTIVE PORTAL NÃO ACEITANDO NOVOS USUÁRIOS

reinaldo.feitosa

Verifica no log o que realmente esta acontecendo, Será se esta chegando no Captive ou seus AP que não suportam a quantidade, ja tive programa parecido e o problema era os roteadores da Intelbras (win240), muito bom de sinal mas trava com o trafego, começa a mandar o mac dele ao invez do mac do cliente e ai o captive portal não se entende.

fabricioborges1

@empbilly:

@fabricioborges1:

@andrezaomac:

@fabricioborges1:

@andrezaomac:

Existe uma opção de Maximo de Concorrentes, ela deve fazer o que vc necessita.

Coloque o valor maior possível lá, pode ser que resolva.

Boa tarde!

Na verdade não… Acredito que essa opção seria no caso de meus roteadores/AP's estarem em NAT, recebendo ip na WAN e servindo uma nova faixa. Mas não é o meu caso. Utilizo os roteadores meio que como "bridge" somente recebendo pela LAN.

A questão é que conecta normalmente, mas do nada trava, as vezes com 55 usuários, ninguém mais consegue autenticar, so se eu desabilitar e habilitar novamente.

Essa opção não ter nada haver com Nat, e sim com a quantidade de usuários conectados.

Mas não seria a quantidade de maquinas com o mesmo ip?
Um router no meio com NAT mudando a faixa e diversos aparelhos conectados nesse roteador pegando dhcp servido por esse novo route. Mas o pfSense reconheceria os equipamentos conectados através desse router.

Ex:
LAN do meu pfSense = 10.1.1.1
DHCP Server do meu pfSense = 10.1.1.100 ~ 10.1.1.200
WAN do meu Router TP-Link = 10.1.1.2
LAN do meu Router TP-LINK = 172.14.14.1
DHCP server= 172.14.14.100 ~ 172.14.14.200
15 Celulares, tablets e Notebooks conectados pegando DHCP do meu Router TP link = 172.14.14.100 ~ 172.14.14.115

Para o pfSense ele entenderia esses 15 dispositivos com somente o IP do TP-LINK 10.1.1.2. (Com essa opção recomendada, que não é o meu caso)
Até por que, acho 100 (que é o máximo permitido nessa opção) um número muito baixo para uma rede inteira (Até mesmo por AP)

Você esta utilizando os APRouters com dhcp ativado ou o exemplo acima é somente um "exemplo"?

É somente um exemplo, numa situação em que a indicação andrezaomac seria válida (da forma em que eu interpretei)
Na realidade não utilizo dhcp ativo nos aps. Tudo na faixa do pfSense.

fabricioborges1

@Reinaldo:

Verifica no log o que realmente esta acontecendo, Será se esta chegando no Captive ou seus AP que não suportam a quantidade, ja tive programa parecido e o problema era os roteadores da Intelbras (win240), muito bom de sinal mas trava com o trafego, começa a mandar o mac dele ao invez do mac do cliente e ai o captive portal não se entende.

Boa tarde!

Primeiramente, obrigado pela sua resposta.
Irei dar uma verificada, embora atualmente o problema esteja de certa forma sanado com a configuração de "Se tiver mais de 4hrs inativo será desconectado".
Deu muita dor de cabeça com o cliente e não vou ter condição de aumentar esse time pra forçar o problema atualmente. Vamos ver se volta a dar o problema, quem sabe no próximo fds com algum evento no local.

Você se refere a função em Status -> System Logs -> Captive Portal Auth ?

cliente.png_thumb

empbilly

fabricioborges1,

Posta uma print das configurações do teu captiveportal.

fabricioborges1

@empbilly:

fabricioborges1,

Posta uma print das configurações do teu captiveportal.

Segue abaixo conforme solicitado.

Cliente1.png_thumb

Cliente2.png_thumb

Cliente3.png_thumb

Cliente4.png_thumb

Cliente5.png_thumb

Cliente6.png_thumb

empbilly

Cara, a principio parece tudo ok. Eu utilizo o captiveportal a muito tempo e já tivemos quase 100 usuários simultâneos e não ocorreu esse problema que contigo ocorre. A diferença é que eu não configurei o "usuário" diretamente na pagina de acesso. Cada usuário precisa informar seu login e senha a cada acesso ou após o tempo de desconexão da rede wifi.

Não sei se isso é motivo para acontecer isso. O que tu pode fazer é remover o valor do "Idle timeou" e com o tcpdump monitorar os acessos. Talvez dessa forma tu descubra algo a mais.
https://doc.pfsense.org/index.php/Sniffers,_Packet_Capture

fabricioborges1

@empbilly:

Cara, a principio parece tudo ok. Eu utilizo o captiveportal a muito tempo e já tivemos quase 100 usuários simultâneos e não ocorreu esse problema que contigo ocorre. A diferença é que eu não configurei o "usuário" diretamente na pagina de acesso. Cada usuário precisa informar seu login e senha a cada acesso ou após o tempo de desconexão da rede wifi.

Não sei se isso é motivo para acontecer isso. O que tu pode fazer é remover o valor do "Idle timeou" e com o tcpdump monitorar os acessos. Talvez dessa forma tu descubra algo a mais.
https://doc.pfsense.org/index.php/Sniffers,_Packet_Capture

Entendi. Nesse cliente que tá ocorrendo o problema não tenho condição de realizar testes, forçar o problema para ver o que esta acontecendo. Mas estou arrumando uma parceiria, vou fornecer um firewall a uma empresa de graça, mas para poder estar realizando testes, acredito que semana que vem já devo ter uma resposta do problema. Minhas suspeitas são exatamente essas, ou os APs não estão aguentando, ou essa configuração da minha pagina html está dando problema. Quem sabe seja um limite de logins com o mesmo usuário.

Mas teria alguma outra forma de utilizar o captive portal somente com uma senha fixa? Sem usuário, sem voucher. só a pagina personalizada e senha.

andrezaomac

Não há possibilidade de deixar SEM SENHA??

E faz uma regra com adegamento de horário e dia.
Ou seja quando o estabelecimento estiver fechado, não há conexão.

Não seria uma saída para sua solução.?

fabricioborges1

@andrezaomac:

Não há possibilidade de deixar SEM SENHA??

E faz uma regra com adegamento de horário e dia.
Ou seja quando o estabelecimento estiver fechado, não há conexão.

Não seria uma saída para sua solução.?

Obrigado pela sua resposta. Poderia ser uma solução válida. Mas acho que não agradaria o cliente deixar sem senha. Além do mais, e um estabelecimento 24hrs (Hotel), então sempre haverá conexão :\

andrezaomac

@fabricioborges1:

@andrezaomac:

Não há possibilidade de deixar SEM SENHA??

E faz uma regra com adegamento de horário e dia.
Ou seja quando o estabelecimento estiver fechado, não há conexão.

Não seria uma saída para sua solução.?

Obrigado pela sua resposta. Poderia ser uma solução válida. Mas acho que não agradaria o cliente deixar sem senha. Além do mais, e um estabelecimento 24hrs (Hotel), então sempre haverá conexão :\

Nesse caso por ser Hotel, sem senha não é viável mesmo.

empbilly

@fabricioborges1:

@empbilly:

Cara, a principio parece tudo ok. Eu utilizo o captiveportal a muito tempo e já tivemos quase 100 usuários simultâneos e não ocorreu esse problema que contigo ocorre. A diferença é que eu não configurei o "usuário" diretamente na pagina de acesso. Cada usuário precisa informar seu login e senha a cada acesso ou após o tempo de desconexão da rede wifi.

Não sei se isso é motivo para acontecer isso. O que tu pode fazer é remover o valor do "Idle timeou" e com o tcpdump monitorar os acessos. Talvez dessa forma tu descubra algo a mais.
https://doc.pfsense.org/index.php/Sniffers,_Packet_Capture

Entendi. Nesse cliente que tá ocorrendo o problema não tenho condição de realizar testes, forçar o problema para ver o que esta acontecendo. Mas estou arrumando uma parceiria, vou fornecer um firewall a uma empresa de graça, mas para poder estar realizando testes, acredito que semana que vem já devo ter uma resposta do problema. Minhas suspeitas são exatamente essas, ou os APs não estão aguentando, ou essa configuração da minha pagina html está dando problema. Quem sabe seja um limite de logins com o mesmo usuário.

Mas teria alguma outra forma de utilizar o captive portal somente com uma senha fixa? Sem usuário, sem voucher. só a pagina personalizada e senha.

A principio somente as opções que mostram na pagina de config.

auth.png_thumb

denicio

Boa noite.
Analisando seu cenário, é possível criar VOUCHERS com duração de 1 ano ou mais ai poderia ate fazer um rotatividade do código que seria bom, e um ano é um bom tempo de duração.
Com relação a travar com certa quantidade de conexões simultâneas, tem que se observar alguns detalhes:

Use a faixa de IPs da rede Hotspot /16 assim o SV DHCP terá mais IPs livres para liberar já que os APs estão em Bridge;
Os APs tem limites de acesso simultâneos principalmente esses APs domésticos que suportam entorno de 16 a 30 conexões (isso se não travar);
Verificar como está o uso do processador, memoria, MBUF Usage e State table size do servidor;
Caso continue a TRAVAR com essa configuração de apenas de usuário desative a autenticação e monitore se vai continuar a travar;

Espero que ajude. ;D

fabricioborges1

@denicio:

Boa noite.
Analisando seu cenário, é possível criar VOUCHERS com duração de 1 ano ou mais ai poderia ate fazer um rotatividade do código que seria bom, e um ano é um bom tempo de duração.
Com relação a travar com certa quantidade de conexões simultâneas, tem que se observar alguns detalhes:

Use a faixa de IPs da rede Hotspot /16 assim o SV DHCP terá mais IPs livres para liberar já que os APs estão em Bridge;

Os APs tem limites de acesso simultâneos principalmente esses APs domésticos que suportam entorno de 16 a 30 conexões (isso se não travar);

Verificar como está o uso do processador, memoria, MBUF Usage e State table size do servidor;

Caso continue a TRAVAR com essa configuração de apenas de usuário desative a autenticação e monitore se vai continuar a travar;

Espero que ajude. ;D

Boa tarde.

Quanto aos vouchers, nessa situação não seria possível, o cliente deseja que mantenha a senha padrão deles.
Quanto aos AP's, estarei verificando na próxima oportunidade de ir a cidade do cliente e verificar suas configurações.
Estamos implementando em um cenário semelhante, mas com a utilização de ap's coorporativos (unifi's da ubnt).
O firewall está bem. E sem o captive não temos problemas. Inclusive, quando trava, acessamos remotamente, desativamos e ativamos novamente o captive portal, assim todos conseguem conexão. (Sempre trava por volta de 50 a 55 conexões simultaneas).

Grato pela resposta, em breve volto com resultado do ambiente de testes. Abrss