@jorlando não uso nenhum dos dois

Bom dia, qual cidade vc é? Sou de Campo GRande - MS e uso o GMT -4, mais precisamente o America/CampoGrande no pfsense, porém estava dando erro tbm. Estou usando o America/Manaus que tbm é -4 e está tudo certo por enquanto. Sugiro escolher outra cidade do raio GMT que vc usa e testar pra ver se funciona igual ocorreu cmg.

O pfsense não rastreia mais de uma conexão por IP público em túneis GRE. O seu problema inclusive é mencionado na documentação: https://docs.netgate.com/pfsense/en/latest/vpn/pptp-troubleshooting.html O protocolo GRE (usado pelo PPTP) em si é encriptado, assim o pfsense não tem como verificar diferentes portas para diferentes usuários. Quem chegar primeiro, leva. Se você tiver mais IPs públicos disponíveis pode mapear 1:1 para seus clientes internos. Um adendo: PPTP é considerado inseguro, por conta de vulnerabilidade no porotoco MSCHAP. Verifique a possibilidade de usar IPSEC ou OpenVPN para esse acesso externo.

Você liberou a porta 445 para o mundo ou apenas a rede com a qual você precisa conexão? Portas referentes a SMB e outros serviços windows faça da maneira mais restrita possível. Alguns serviços do Windows além de serem muito vulneráveis são vetores de ataque. o Active Directory é usado para DDoS, por exemplo. Um usuário ma intencionado faz usa pacotes forjados com o endereço da rede que ele quer derrubar para sua rede. Faz requisições de 40, 50 byes e obtém respostas de mais de 1500 bytes. Senta a rede a da vítima. E a sua.

@NogBadTheBad Thank you so much for informing me and helping me! Thx

Ninguém sabe?

Vou olhar. Valeu!!!

@tiagocardoso @michael-lopes Obrigado pela disposição em ajudar o próximo! Então, essa alternativa eu já conhecia. Como a rede do cliente é grande, não seria viável fazer por grupos baseado em IP. Nossa ideia seria com regras baseada em usuários/grupos do AD, após algumas pesquisas descobri o pacote UserAuth. Estamos testando em lab, acredito que possa atender a nossa demanda. Obrigado! Att, Eber

Galera, fiz um teste parando o serviço de NTP clock sync. Voltou a funcionar. Vamos ver se é isso.

Alguém conseguiu resolver esse erro? Também estou passando por ele!

Olá! Também estou enfrentando esse problema, aparentemente do nada. O Squid + Squidguard + AD funcionava bem e de repente começou a dar esse erro. Tanto o net ads info quanto o wbinfo -u retornam informação normalmente. Os tickets do kerberos tb estão válidos. Não importa a quantidade de filhos/helpers configurados (já coloquei de 20 até 200), o estado visto pelos logs é o mesmo - kid1| Starting new negotiateauthenticator helpers... - como se fosse um loop. Alguém tem alguma idéia sobre isso? Abs!

Se está correto, você deve estar recebendo conexões na porta UDP 1194, provenientes do seu cliente. E deve haver logs de conexão no servidor de openvpn e também logs de firewall na porta 1194.

Olha, olhando o problema superficialmente, com as informações que você passou, já levando em consideração que você verificou cabos e etc, digo que sim o problema pode ser na placa de rede. Não é normal ter problema de conectividade entre o pfsense e o modem, é um cabo, não é pra perder ping nem muito menos perder o MAC da tabela.