Messages

[Este erro indica que o endereço IP que você está tentando usar já está em uso ou não está disponível na interface especificada.]

Boa tarde, bhillcv!

Essa configuração deveria funcionar sim com IPs VIP.
Basta criar o IP VIP do tipo CARP, configurá-lo adequadamente no HA e estando tudo correto com o IP VIP CARP, ele poderá ser usado em qualquer local do firewall.

Pelo erro que nos enviou há um indício de problema com o seu IP VIP:

"Error   openvpn_server3   TCP/UDP: Socket bind failed on local address [AF_INET]189.99.167.226:1198: Can't assign requested address (errno=49)"

Este erro indica que o endereço IP que você está tentando usar já está em uso ou não está disponível na interface especificada.

Recomendamos que faça uma checagem mais minuciosa com relação ao seu IP VIP antes de configurá-lo na VPN.
Como a própria mensagem indicou, pode haver conflito de IPs entre seus dispositivos.

Boa tarde, Junior!

Você pode fazer isto via uma Policy-based routing.
Primeiro faça 3 Aliases: um com as portas UDP, outro com as portas TCP e mais um com as redes privadas da RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)

Depois de feito isto, crie uma nova regra na interface que irá utilizar esta regra:
- Caso seja a LAN, crie uma regra com Protocolo UDP onde a origem seja a própria LAN;
- O destino deverá ser o alias da RFC1918, porém marque a caixa "Destination / Invert" (o que vai deixar um símbolo de "!" no alias), para que este destino seja a exceção da regra;
- Na configuração de PORTAS coloque o Alias de portas UDP que criou anteriormente;
- E por último, na opção "Gateway", selecione o link que deseja que esta comunicação.

Faça mais uma regra idêntica (podendo "clonar" a anterior), mas altere:
- O protocolo para TCP
- Configuração de PORTAS coloque o Alias de portas TCP que criou anteriormente;

Deste modo você fará com que toda a comunicação UDP e TCP para qualquer IP Destino - com exceção os IPs privados (RFC1918) - e quando as portas destino forem as que estão nos ALIAS que configurou, saia através do Gateway que fixou na regra.

Por favor nos informe caso haja alguma dúvida.

Boa tarde, @mailtongom!

Não conhecemos casos de diferença de navegação entre links só pelo tipo de conexão dos mesmos.
O modo em que o firewall se comunica com o provedor não deveria influenciar nos acessos.
Assim que o firewall consegue chegar ao gateway da operadora, ele passa a seguir a rota da mesma.

Se seu link "A" chega nos acessos em questão mas o link "B" não chega, esta situação pode ser um problema de rota da operadora "B".

Recomendamos que entre em contato com a operadora que você percebe o erro de acesso para que eles confirmem se há algum problema de rota. Provavelmente eles irão te pedir testes de acesso enquanto eles olham os LOGs deles.

[1]

Boa tarde, Jader!

Não recebemos, até hoje, nenhum relato de problema com PPPoE no OPNSense.
Mas antes de tirarmos conclusões, poderia nos informas alguns pontos, por favor:

1 - Você nos informou que está utilizando um dispositivo externo (não utilizando da própria operadora). Sabendo disso, sabe nos informar se com o próprio modem da operadora - que permite alterar para bridge também - ocorre este mesmo problema?

2 - Tentou usar seu Intelbras em PPPoE em um outro dispositivo, como um notebook com configurações de "discagem" PPPoE e ver o comportamento?

3 - Os firmwares do OPNsense e do seu dispositivo Intelbras estão atualizados?


Aguardo suas respostas para darmos continuidade na análise.

[entrada]

Olá, Ruiter!

Caso seu problema seja entrada, ou seja, uma utilização de acesso remoto aos seus dispositivos atrás do firewall utilizando o Logmein, será necessário liberar as portas indicadas por eles no link via NAT de Entrada .
> Obs.: Recomendamos que todos os NATs de entrada sempre sejam feitos com IP de origem definidos, a fim de evitar problemas com segurança.

E caso seja saída, (dispositivos de sua rede atrás do firewall tentando acessar algum outro dispositivo via Logmein), e como você está utilizando Proxy Transparente, será necessário verificar as regras de proxy a fim de permitir o acesso ao Logmein.
Por exemplo: se toda sua rede tem a necessidade de acessar o Logmein, deve-se liberar na Whitelist de seu Proxy os domínios indicados no site deles.

E caso seja outro tipo de problema que está enfrentando, favor nos informar.

[--duplicate-cn]

Boa tarde, Paulo!

Há uma linha no LOG que me chamou atenção:

"OpenVPN log message meaning WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want"

A opção "duplicate-cn" permite que várias conexões usem o mesmo nome comum (CN), o que significa que um único certificado pode ser usado por mais de uma conexão ou usuário.
Por outro lado, a opção "client-config-dir" é usada para especificar um diretório contendo arquivos de configuração específicos do cliente.

Usar essas duas opções juntas pode causar comportamentos inesperados, pois "duplicate-cn" permite que vários clientes usem o mesmo certificado, enquanto "client-config-dir" espera que cada cliente tenha seu próprio arquivo de configuração.
Portanto, a menos que você tenha um motivo específico para usar essas duas opções juntas, geralmente é recomendado não fazer isso.

Recomendamos revisar sua real necessidade e decida qual das duas opções você irá desabilitar.
Assim que o fizer, favor nos informar se funcionou corretamente.

[exemplo.local]

Bom dia, Notrevor

Veja abaixo se entendi corretamente.
Vocês possuem uma página configurada em um servidor interno "exemplo.local" e um DNS público cadastrado como "exemplo.com.br". Seria isso?

Caso seja, para que você consiga acessá-lo no "com.br" utilizando o IP LOCAL deste server, será necessário cadastrar um DNS interno diretamente no seu OPNSense.
O DNS padrão do OPNSense é o DNS Unbound.

Aponte o IP LOCAL de seu servidor, vinculando-o ao DNS "exemplo.com.br".

Deste modo todos que tiverem seu firewall como DNS, irão resolver está página preferencialmente via DNS interno.

Ola, Paulo!

Pelo que nos informou, está tudo correto.

Consegue nos enviar sua configuração completa da OpenVPN em questão?
Caso consiga enviar as screenshots de toda a configuração desta OpenVPN,  nós poderemos fazer uma análise detalhada.

[OpenVPN Clent to Server]

Boa tarde, Paulo!

Pelo que você nos descreveu, aparenta estar correto, mas para que possamos lhe ajudar, precisaremos de mais alguns detalhes.

Toda a OpenVPN Clent to Server possui um range de IP específico configurado a ser usado pelos usuários que conectam-se ao mesmo. Esta rede do túnel que deve ser liberada na regra de firewall como sendo a origem.

Resumidamente, para que uma OpenVPN funcione corretamente ela precisa ter Rotas e Regras bem configuradas.

Sobre as Rotas, na OpenVPN Server há o campo específico para inserir as redes que poderão ser acessadas por este túnel:  "IPv4 Local Network"

E sobre as Regras, as liberações de acessos das OpenVPNs Client to Server são feitas na interface com nome de "OpenVPN".

A Regras deverão ser feitas no seguinte padrão:

IP Origem: Rede do Túnel OpenVPN (que foi configurada no Server);
Porta Origem: Nenhum;
IP Destino: IP(s) ou Rede(s) que os usuários desta OpenVPN poderão acessar;
Porta Destino: Porta(s) que os usuários desta OpenVPN poderão acessar;

• Caso queira nos enviar imagens de sua configuração da OpenVPN e das Regras, podemos lhe ajudar a tentar encontrar o que ainda falta ser feito.

Bom dia!

Poderia,por favor, nos dar mais detalhes sobre suas configurações?

Por exemplo:

- Está usando Proxy?
- Caso esteja usando Proxy, seria o explícito ou o transparente?
- E ainda no caso de usar Proxy, ao tentar acessar a página, poderia nos enviar os LOGs deste acesso?
- Já tentou criar uma regra de saída sem restrição para o IP que está testando e ver se o acesso fica OK?

[STATES]

Bom dia, rogeracioly!

Isto ocorre devido a configuração de Nat Outbound, que é necessária para que a LAN possa se comunicar com a internet.

Você já tentou filtrar esta comunicação no STATES (Firewall: Diagnostics: States) ou no PACKET CAPTURE (Interfaces: Diagnostics: Packet Capture) ?

Nestas opções você terá maiores detalhes dos IPs envolvidos.

[DNS Unbound]

Bom dia, Anderson!

Este é um problema que ocorre em alguns casos de certos tipos de dispositivos que utilizam o DNS Unbound do OPNSense.

Abaixo há uma discussão sobre este assunto:

https://forum.opnsense.org/index.php?topic=23087.0

O mais comum de dar este problema é quando usam-se dispositivos REDMI.
Vi que no seu caso o causador do conflito foi um outro dispositivo: MI8Lite

Uma das soluções seria a o que você fez (desativou o release) e uma outra seria deletar a linha específica deste registro (do dispositivo que deu erro) no caminho abaixo:
/var/unbound/dhcpleases.conf

Ainda não conseguimos validar se este dispositivo "problemático" voltar a consultar o DNS Unbound, irá causar o mesmo problema novamente.

Caso queira evitar problemas futuros, você também pode usar um outro serviço de DNS do OPNSense, que é o DNSCrypt-Proxy.

Lembrando que se decidir trocar o serviço de DNS usado no firewall, sempre desabilite o antigo antes de ativar o novo.

[System: Access: Users]

Boa tarde!

Abaixo enviaremos um tutorial resumido dos passos necessários para que o 2FA funcione juntamente com autenticação via Microsoft AD:

> Escolher o tipo "LDAP + Timebased One Time Password";
> Hostname os IP address: Insira o IP do servidor AD;
> Bind Credencials: Insira um usuário válido no AD, o qual tenha permissões de leitura nos grupos que desejar.
> Base DN: Caminho do AD;
> Authentication containers: Selecione os locais permitidos onde este novo server irá consultar as autenticações;
> Extended Query: pode ser usada para selecionar usuários que são membros de um grupo específico (relevante apenas para serviços externos, quando não estiver usando o banco de dados de usuários local). Pode-se usar algo como: & (memberOf = CN = meuGrupo, CN = Usuários, DC = opnsense, DC = local)

Após isto, será necessário importar os usuários do AD para o firewall.
Você consegue importar em System: Access: Users, ao lado do sinal "+" no um ícone de formato de nuvem.

Caso este ícone no formato de nuvem não esteja aparecendo ao lado do "+", será necessário escolher o server AD que foi configurado no firewall em: System: Settings: Administration.
Nesta tela ache a opção Authentication e selecione na caixa de seleção ao lado o server recém criado.
Obs.: NÃO DESMARQUE A OPÇÃO LOCAL DATABASE.

Quando o icone de nuvem ficar visível em System: Access: Users, ao clicar no mesmo será aberta uma janela com os usuários do AD que cadastrou no firewall.

Selecione os usuários que deseja importar para o firewall depois abaixo clique em "Save".

Quando o usuário de AD estiver listado no firewall, localize-o e depois clique em editar.
Localize a opção OTP seed para poder gerar um novo.

Salve, volte no mesmo usuário e gora você poderá capturar a chave via OTP Seed ou via QR Code do usuário em questão.

Boa tarde, Anderson!

Se eu entendi corretamente, você desabilitou a regra padrão de saída liberada do seu firewall e liberou somente 3 portas para sua rede LAN: 53, 443 e 80. Estou correto?
Caso seja isto, para liberar a saída para a porta 37777, basta incluí-la também como porta autorizada a ser acessada pela sua LAN.

[https://forum.opnsense.org/index.php?topic=26103.0;topicseen]

Olá!

Para que você consiga conectar a OpenVPN em quaisquer dos links de internet, (independente de ser default ou não), será preciso alterar a interface de conexão da mesma de "any" para "localhost".
Quando usado o "localhost" como intermediador das conexões na OpenVPN, a VPN "Client" é que escolhe qual link quer se conectar.

É o mesmo procedimento já explicado no link abaixo:

https://forum.opnsense.org/index.php?topic=26103.0;topicseen


Qualquer dúvida, favor informar.