Messages

Seja bem vindo @Gabriel.

@erisnaldo, Seja muito bem vindo ao fórum do OPNsense.
esperamos que tenha uma boa experiência participando por aqui.

Hi VN, welcome!

That would be very much appreciated, and I fully understand the dynamic nature of aliases.

That said, I wouldn't mind if adding a new network to HQ_NETWORKS_ALIAS triggered a reload of the OpenVPN service that references this alias. This is not something I would do frequently, and when I do, I would already be clicking Apply on the OpenVPN configuration page, which reloads the service anyway.

This behavior would also be a significant facilitator for static routes, Wireguard, OpenVPN, and IPsec.

For now, doing the manual approach...

[Will I be able to set up a VPN gateway with double NAT?]

Will I be able to set up a VPN gateway with double NAT?
Yes. As long as the ISP-provided combo router allows you to configure a DMZ or perform port forwarding to your firewall, this will work. OpenVPN, in particular, works very well in this type of setup and is usually the easiest option.

Am I okay with double NAT if my OPNsense LAN uses something like 192.168.0.x or 192.168.1.x?
yes.


Since I don't want to buy an additional access point, I plan to connect my laptop to the ISP router's guest Wi-Fi and then use the VPN to access the rest of the network (rsync, cloud access, remote development, pulling compiled packages, etc.). Is this fine, or is there a better approach?
That's a perfectly valid and straightforward approach. The VPN will give you access to internal hosts and services without requiring complex port-forwarding rules.

-----
Regarding individual port forwarding: the behavior is exactly as you described. Port forwards expose only specific services, while the DMZ forwards all unsolicited inbound traffic to a single internal address (your firewall?).

Personally, I tend to use the DMZ approach. It allows the firewall to block unwanted connections centrally and provides data for my SIEM. That said, forwarding only specific ports is also perfectly fine and will work as expected.

Hi diyordie, welcome to the OPNsense user forum.
I hope you have a great experience with OPNsense.

If the ISP-provided combo router does not allow the configuration of static routes, double NAT is not necessarily an issue. In this case, you can configure the DMZ on the ISP router to point to the firewall's WAN IP address. With this setup, all inbound traffic initiated from the Internet to your public IP will be forwarded to the firewall, while other devices connected directly to the ISP router (for example, via Wi-Fi) will remain outside the firewall's management.

Use nsoluoes_ti,

Use o plugin `os-ftp-proxy`.

O problema acontece porque o cliente FTP ao enviar o comandos PASV (entrar no modo passivo), instrui o serivdor a abrir um canal de dados em outra porta, e deve estar havendo o bloqueio neste ponto.

O plugin mencionado acima intercepta as conexões ftp na lan e faz um intermédio (proxy) entre servidor-ftp <> firewall <> cliente.
Pra gente já resolveu.

PS.:
no pfsense, deve haver alguma outra regra que não foi portada para o opnsense.
veja se não tem nenhum port forward (encaminhamento de porta) com reflection habilitado e fazendo conflito.
ou se há algum port forward na wan fazendo encaminhamento de portas altas para um servidor/pc interno específico. já peguei este cenário com câmeras/dvr/voip.
se possível, faz uma captura de pacotes em todas as interfaces, com filtro no campo hosts com o ip do servidor. já ajudar diagnosticas quem enviou o último pacote, e qual foi a porta alta usada no pasv.

Update:
Podemos usar o cliente connect mais recente usando o túnel criado como instance. Yay! 
Ao exportar a configuração (client export), no campo de texto livre, adicione as seguintes opções:

Code Select Expand

dhcp-option DOMAIN-SEARCH mydomain.local
dhcp-option ADAPTER_DOMAIN_SUFFIX mydomain.local


[Wireguard matriz filial redundante com BGP]

Wireguard matriz filial redundante com BGP


🔃 Roteamento Dinâmico
Status: Validado v25.7


Já vimos como configurar o roteamento estático adicionando rotas na tabela de roteamento do firewall e definindo o gateway responsável por transportar aquele tráfego. Agora vamos ver como fazer esse cenário mas usando o roteamento dinâmico, no qual a rota é negociada entre os firewalls, e geralmente é um cenário ideal para ser usado em túneis de VPN de forma redundante já que tanto o IPSec quanto o Wireguard não possuem nativamente a redundância de Túneis.

Cenário
Para exemplificar o roteamento dinâmico e demonstrar seu potencial, iremos estabelecer 2 túneis Wireguard entre 2 unidades remotas e iremos rotear o tráfego com alta disponibilidade, de forma que se cair um dos túneis, haverá uma convergência do tráfego para o segundo túnel disponível.

Premissas
1. Matriz possui 2 Links de internet com IPs públicos;
2. Matriz será o lado servidor da conexão, ou seja, apenas recebe conexões vindas da filial.
3. Filial pode possuir links dinâmicos ou estar atrás de CGNAT.
4. LAN da Matriz: 192.168.1.0/24.
5. LAN da Filial: 192.168.2.0/24.
6. Será usado iBGP, ou seja, apenas troca de rotas entre 2 peers diretamente conectados.
7. Serão negociadas apenas as redes LAN de cada peer/firewall.


Configurando os Túneis Wireguard

No Firewall Matriz

Acesse o menu VPN → Wireguard → Instances.
  Marque a caixa Enable Wireguard e clique em Apply.

  Clique em "+ Add" para adicionar uma nova instância.
  Marque a opção Advanced mode no topo da tela.
  Preencha o nome da instância com Tunel-Matriz-Filial-A
  Clique no ícone da engrenagem a frente de Public key para gerar o par de chaves pública/privada.
  Preencha Listen port com 51820.
  Preencha o Tunnel Address com 192.168.66.1/30
  Marque a opção Disable routes.
  Preencha o campo gateway com 192.168.66.2
  Clique em Save.

  Clique em "+ Add" para adicionar uma nova instância.
  Marque a opção Advanced mode no topo da tela.
  Preencha o nome da instância com Tunel-Matriz-Filial-B
  Clique no ícone da engrenagem a frente de Public key para gerar o par de chaves pública/privada.
  Preencha Listen port com 51821.
  Preencha o Tunnel Address com 192.168.67.1/30
  Marque a opção Disable routes.
  Preencha o campo gateway com 192.168.67.2
  Clique em Save.
  Clique em Apply.


No Firewall Filial

Acesse o menu VPN → Wireguard → Instances.
  Marque a caixa Enable Wireguard e clique em Apply.
 
  Clique em "+ Add" para adicionar uma nova instância.
  Marque a opção Advanced mode no topo da tela.
  Preencha o nome da instância com Tunel-Matriz-Filial-A
  Clique no ícone da engrenagem a frente de Public key para gerar o par de chaves pública/privada.
  Preencha Listen port com 51820.
  Preencha o Tunnel Address com 192.168.66.2/30
  Marque a opção Disable routes.
  Preencha o campo gateway com 192.168.66.1
  Clique em Save.

  Clique em "+ Add" para adicionar uma nova instância.
  Marque a opção Advanced mode no topo da tela.
  Preencha o nome da instância com Tunel-Matriz-Filial-B
  Clique no ícone da engrenagem a frente de Public key para gerar o par de chaves pública/privada.
  Preencha Listen port com 51821.
  Preencha o Tunnel Address com 192.168.67.2/30
  Marque a opção Disable routes.
  Preencha o campo gateway com 192.168.67.1
  Clique em Save.
  Clique em Apply.




Configurando os Peers Wireguard

No Firewall Matriz

Acesse o menu VPN → Wireguard → Peers.
  Clique em "+ Add" para adicionar um novo Peer.
  Preencha o nome da instância com Tunel-Matriz-Filial-A
  Copie a chave Pública gerada na Instância "Tunel-Matriz-Filial-A" do *Firewall da Filial* e cole no campo Public Key.
  Preencha Allowed IPs com 0.0.0.0/0.
  Deixe os campos "Endpoint Address" e "Endpoint port" vazios.
  No campo Instances selecione a Instância Tunel-Matriz-Filial-A.
  Em Keepalive interval insira 10.
  Clique em Save.
 
  Clique em "+ Add" para adicionar um novo Peer.
  Preencha o nome da instância com Tunel-Matriz-Filial-B
  Copie a chave Pública gerada na Instância "Tunel-Matriz-Filial-B" do *Firewall da Filial* e cole no campo Public Key.
  Preencha Allowed IPs com 0.0.0.0/0.
  Deixe os campos "Endpoint Address" e "Endpoint port" vazios.
  No campo Instances selecione a Instância Tunel-Matriz-Filial-B.
  Em Keepalive interval insira 10.
  Clique em Save.
  Clique em Apply.


No Firewall da Filial

Acesse o menu VPN → Wireguard → Peers.
  Clique em "+ Add" para adicionar um novo Peer.
  Preencha o nome da instância com Tunel-Matriz-Filial-A
  Copie a chave Pública gerada na Instância "Tunel-Matriz-Filial-A" do *Firewall da Matriz* e cole no campo Public Key.
  Preencha Allowed IPs com 0.0.0.0/0.
  Em Endpoint Address preencha com o primeiro IP Público da Matriz.
  Preencha o Endpoint port com 51820.
  No campo Instances selecione a Instância Tunel-Matriz-Filial-A.
  Em Keepalive interval insira 10.
  Clique em Save.
 
  Clique em "+ Add" para adicionar um novo Peer.
  Preencha o nome da instância com Tunel-Matriz-Filial-B
  Copie a chave Pública gerada na Instância "Tunel-Matriz-Filial-B" do *Firewall da Matriz* e cole no campo Public Key.
  Preencha Allowed IPs com 0.0.0.0/0.
  Em Endpoint Address preencha com o segundo IP Público da Matriz.
  Preencha o Endpoint port com 51821.
  No campo Instances selecione a Instância Tunel-Matriz-Filial-B.
  Em Keepalive interval insira 10.
  Clique em Save.
  Clique em Apply.


Configurando as Regras de Firewall

No Firewall Matriz

Acesse o menu Firewall → Rules → WAN1.
  Clique em "+ Add" para adicionar uma nova Regra para liberar a conexão VPN.
  Em protocolo selecione UDP.
  Em Destination selecione This Firewall
  Em Destination Port Range selecione Other e preencha o campo From com 51820 e o campo To com 51820
  Marque a caixa Log.
  Insira a seguinte descrição: Libera VPN Wireguard
  Clique em Save
  Clique em Apply changes.

Acesse o menu Firewall → Rules → WAN2.
  Clique em "+ Add" para adicionar uma nova Regra para liberar a conexão VPN (no segundo link).
  Em protocolo selecione UDP.
  Em Destination selecione This Firewall
  Em Destination Port Range selecione Other e preencha o campo From com 51821 e o campo To com 51821
  Marque a caixa Log.
  Insira a seguinte descrição: Libera VPN Wireguard
  Clique em Save
  Clique em Apply changes.

Acesse o menu Firewall → Rules → Wireguard (Group).
  Clique em "+ Add" para adicionar uma nova Regra para liberar o tráfego dentro do túnel.
  Marque a caixa Log.
  Insira a seguinte descrição: Libera Trafego VPN Wireguard
  Clique em Save
  Clique em Apply changes.


No Firewall da Filial

Acesse o menu Firewall → Rules → Wireguard (Group).
  Clique em "+ Add" para adicionar uma nova Regra para liberar o tráfego dentro do túnel.
  Marque a caixa Log.
  Insira a seguinte descrição: Libera Trafego VPN Wireguard
  Clique em Save
  Clique em Apply changes.




Verificando os Túneis

No Firewall Matriz

Acesse o menu VPN→ Wireguard→ Status.
Verifique se todos os túneis foram conectados com sucesso como na imagem abaixo (coluna status verdinha).

Caso alguma das conexões não tenha sido estabelecida (ícone vermelho), reveja as etapas acima novamente. Verifique se ambos os firewalls consegue se comunicar por ambos os links de internet.



Instalando Plugin OS-FRR para Roteamento Dinâmico

Em ambos os Firewalls

  Navegue até System → Firmware → Plugins.
  Localize e instale o plugin os-frr
  Atualize a página para aparecer o menu "Routing"


Habilitando o Roteamento Dinâmico

Em ambos os Firewalls

  Navegue até Routing → General.
  Marque a opção Enable para habilitar o roteamento dinâmico.
  Clique em Apply.


Configurando o Roteamento Dinâmico

No Firewall Matriz

Habilite o BGP
  Acesse o menu Routing → BGP.
  Marque a opção Enable.
  Preencha o campo Network com a rede LAN da matriz, no formato CIDR. Exemplo: 192.168.1.0/24.
  Clique em Apply.

Cadastre os Vizinhos BGP
  Acesse a guia Neighbors
  Clique em "+ Add" para adicionar um novo vizinho BGP.
  Preencha o campo description com: Tunel-Matriz-Filial-A
  Em Peer-IP preencha o endereço 192.168.66.2
  Em Remote AS preencha 65551
  Marque a opção BFD.
  Marque a opção Advanced mode no canto superior esquerdo do formulário.
  Preencha o campo Weight (peso desta rota) com 500.
  Clique em Save.

  Clique em "+ Add" para adicionar um novo vizinho BGP.
  Preencha o campo description com: Tunel-Matriz-Filial-B
  Em Peer-IP preencha o endereço 192.168.67.2
  Em Remote AS preencha 65551
  Marque a opção BFD.
  Clique em Save.
  Clique em Apply.

Habilite o BFD
  Acesse o menu Routing → BFD.
  Marque a opção Enable.
  Clique em Apply.


No Firewall da Filial

Habilite o BGP
  Acesse o menu Routing → BGP.
  Marque a opção Enable.
  Preencha o campo Network com a rede LAN da filial, no formato CIDR. Exemplo: 192.168.2.0/24.
  Clique em Apply.

Cadastre os Vizinhos BGP
  Acesse a guia Neighbors
  Clique em "+ Add" para adicionar um novo vizinho BGP.
  Preencha o campo description com: Tunel-Matriz-Filial-A
  Em Peer-IP preencha o endereço 192.168.66.1
  Em Remote AS preencha 65551
  Marque a opção BFD.
  Marque a opção Advanced mode no canto superior esquerdo do formulário.
  Preencha o campo Weight (peso desta rota) com 500.
  Clique em Save.

Clique em "+ Add" para adicionar um novo vizinho BGP.
  Preencha o campo description com: Tunel-Matriz-Filial-B
  Em Peer-IP preencha o endereço 192.168.67.1
  Em Remote AS preencha 65551
  Marque a opção BFD.
  Clique em Save.
  Clique em Apply.

Habilite o BFD
  Acesse o menu Routing → BFD.
  Marque a opção Enable.
  Clique em Apply.


Verificando a Configuração

Em Ambos os Firewalls

Acesse o menu Routing → Diagnostics → General.
Acesse a guia Running Configuration.
Verifique se há configuração correspondente (seções router-bgp e address-family).
Caso não tenha carregado a configuração, tente rever todo o processo para garantir que não deixou nenhuma etapa de fora da configuração.



Validando a Comunicação

Para validar a comunicação de rede entre as unidades, use um computador de cada unidade e dispare um PING entre eles.
Não se esqueça que deverá haver regras na interface LAN de cada firewall, permitindo a rede LAN local comunicar com a rede LAN remota.
Use o `tracert` para garantir que a rota está saindo pelo túnel VPN ao invés de um link de internet específico definido através de Policy Routing (gateway explícito em regras da LAN).



Qual Túnel Está sendo Usado Preferencialmente?

No firewall da Matriz

Acesse o menu Routing → Diagnostics → BGP
Podemos ver que a melhor rota para a rede da Filial é o túnel que definimos um peso (Weight) de 500. Portante este é o túnel sendo utilizado.

Olá John. seja bem vindo ao fórum do OPNsense.
Vai usar OPNsense nas duas pontas?
IP fixo em ambas as pontas?
Conexões de Internet redundantes?

De forma geral, recomendo usar wireguard roteado, com túneis redundantes e roteamento dinâmico (bgp) para alta disponibilidade do túneis.
Também pode aproveitar o bgp e enviar a rota/prefixo 0.0.0.0/0 para a filial.
Não esquece de criar um NAT de saída na matriz, mascarando os endereços de origem da filial ao saírem pelo(s) links de internet.

Tenho o procedimento do wireguard/bgp. se quiser, envia o teu e-mail no pv que envio o procedimento.

Hi,

This issue is due to code incompatibility, as the core has undergone changes in how it handles runtime model fields.

For now, instead of using the Capitole URL that provides the full set of categories, we must insert them one by one using the links available at:
https://dsi.ut-capitole.fr/blacklists/download/

just register the ones you want to block.

We accomplished that by adding a static route with the endpoint as the target/32 and associating the corresponding gateway.
Another scenario we have (for failover purposes) is to use two tunnels with BGP to weight the preferred path.

Olá,

Após atualização para a versão 25.1.x, passamos a receber o erro abaixo em alguns firewalls:

Code Select Expand

[16-Mar-2025 11:41:18 UTC] PHP Warning:  PHP Startup: Unable to load dynamic library 'mongodb.so' (tried: /usr/local/lib/php/20230831/mongodb.so (Cannot open "/usr/local/lib/php/20230831/mongodb.so"), /usr/local/lib/php/20230831/mongodb.so.so (Cannot open "/usr/local/lib/php/20230831/mongodb.so.so")) in Unknown on line 0


O erro é corrigido logando via ssh no firewall e rodando o comando para remover a biblioteca php/mongo que erroneamente não está em uso:

Code Select Expand

pkg install -y php83-pecl-mongodb-1.19.0


Update: Para a versão 25.1.7 usar o comando abaixo:

Code Select Expand

pkg install -y php83-pecl-mongodb-1.21.0


Olá Pipe!
Calma, não criemos pânico! hehehe
Sei bem como é, já passei uns perrengues assim.
Mas desde que passei a trabalhar com um fornecedor bacana e com appliances validados, tenho usado menos gadernal.

Primeira coisa, tu tá usando realtek. Arranca fora. Sem mais nem menos. Não importa que tenha alterado a atribuição (assignment) da lan para a placa Intel, a realtek continua lá.
Não importa que tenha instalado o driver novo via os-realtek... se algo tem a chance de dar errado, vai dar errado.

Pra gente te ajudar, tu vai ter que dar detalhes.
Qual a versão do opnsense antes?
Qual o hardware?
Quais funções habilitadas?
Gerou algum log ou stacktrace? (bolinha laranja que fica acesa no canto superior da tela antes da caixa de pesquisa.

Esse cenário que mencionou é típico de incompatibilidade de drivers. Aposto que instalou outro firewall baseado em linux, e aí estabilizou. linux funciona melhor com realtek.

Outra coisa. Versão 25.1 acabou de sair. Volta pro barco até estar estável, fica na 24.1 ou 24.7.
É só olhar aqui no fórum que vai ver uma lista grande de problemas com a 25.1:

https://forum.opnsense.org/index.php?topic=45842.msg229386#msg229386
[...]

Olá Pipe,
É possível sim.
No firewall matriz ao cadastrar o Peer referenciando a filial, no campo "Allowed IPs" você preenche com o endereço IP de túnel da Filial, ex.: 10.9.0.2/32 e também com os hosts da filial na qual a matriz terá acesso. ex.: 172.16.0.10/32 172.16.0.15/32 (hosts na lan filial).

DIRECTOR CUT
TL;DR;

Resumindo, a partir da versão 24.7.3, para pesquisar múltiplos termos na caixa de pesquisa, como no exemplo de usuário autenticado na vpn, ficariam assim:
filtro: "ludarkstar99 Peer Connection Initiated".

*sem as aspas é claro.
Lembrando que Só haverá resultado se todas as palavras forem encontradas dentro da linha do log.


Olá,
espero que estejam todos bem.

Hoje pretendo falar sobre algo que me revira a cabeça, a lá Roberta Miranda. e é sobre LOGS.
Mais especificamente sobre pesquisa em LOGS.
Você já tentou pesquisar algo nos logs da VPN, como achar as datas de autenticações de um determinado usuário, ou mesmo procurar uma conexão presa através da tela de states (ou sessions)? Então você já deve ter se perguntado, como preencher a abençoada caixinha de pesquisa para filtrar "da melhor maneira" e trazer os dados na tela com um filtro apurado para encontrar rapidamente o que procura.
Pois bem, como diria um famoso youtuber (de mala e cuia): "Vem comigo!"

PARA COMEÇAR TEM QUE COMEÇAR DO COMEÇO
Eu pretendo lhe mostrar como funciona a pesquisa, e que lhe sirva de futuras referências quando precisar investigar esse tipo de problema. Eu precisei e ninguém me explicou como fazer, então estou deixando o rastro pra você não falar que ninguém te ajudou. A faca tá aí, corta o queijo quem quer!
Primeiro vamos ver como era a pesquisa em um firewall rodando a versão "OPNsense 24.1", sim, tem que ver o passado pra encarar o futuro. Larga de ser preguicinha e vai estudar rapaz...
Acessando o menu "VPN > OpenVPN > Log File" você é apresentado a tela de consulta aos logs mais recentes do openvpn. Esta tela apresenta uma listagem paginada dos logs, e se olhar no canto superior direito, vai ver que tem uma barrinha de pesquisa para procurar informações em específico. Tente conectar na VPN e voltar nesta tela e pesquisar pelo seu login de conexão openvpn. Não esqueça de marcar o nível de severidade como DEBUG para vermos todas as mensagens. Você verá que irá listar as entradas de log que contém o teu login. Até aí perfeito.

Date   Severity   Process   Line
2025-02-19T20:41:27-03:00   Notice   openvpn_server4   ludarkstar99/177.177.177.177:51645 SIGUSR1[soft,ping-restart] received, client-instance restarting
2025-02-19T20:41:27-03:00   Notice   openvpn_server4   ludarkstar99/177.177.177.177:51645 [ludarkstar99] Inactivity timeout (--ping-restart), restarting
2025-02-19T08:16:14-03:00   Notice   openvpn_server4   ludarkstar99/177.177.177.177:51645 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt

Agora, vamos supor que você está buscando fazer uma auditoria nos acessos do ludarkstar99. Apenas filtrar pelo login do usuário vai trazer diversas mensagens (assumindo que está usando nível de log 3/4 no openvpn) e que não são exatamente do login. Algumas sobre inatividade, outras sobre criptografia ou mesmo certificado. E se você quiser trazer apenas as linhas de log de autenticação?
Bom então vamos atrás do filtro. Primeiro você precisa encontrar uma linha modelo. Desconecte e conecte na vpn novamente, atualize a tela rapidamente e irá conseguir localizar uma linha com o texto abaixo, indicando uma autenticação bem sucedida:
177.177.177.177:51645 [ludarkstar99] Peer Connection Initiated with [AF_INET6]::ffff:177.177.239.204:51645 (via 177.39.39.39%vmx0_vlan301)

Vamos dizer que você queira pesquisar os logins bem sucedidos. Então joga na caixa de pesquisa o termo "Peer Connection Initiated with". Logo virá o login de todos os usuários na VPN e não somente o usuário que você está buscando. Você deve estar pensando - é fácil, é só colocar o nome do usuário entre colchetes seguido da frase de conexão bem sucedida como em "[ludarkstar99] Peer Connection Initiated with". Tente aí então espertão, e verá que não trará resultado nenhum! Isso basicamente ocorre porque o opnsense substitui caracteres especiais como "+&$()[]" dentre vários outros. Então... como filtrar tanto pelo nome do usuário junto da frase ou termo que indica um login bem sucedido?
Santa Barbatana Batman! Como não pensei nisso antes. Se é pesquisa de logs, deve haver algum tipo de expressão regular, ou caracteres curingas, geralmente sempre tem! Pois bem. e realmente tem, mas não é tão simples assim.


OS PRUDENTES VEEM O PERIGO E SE ABRIGAM, MAS OS SIMPLES SEGUEM ADIANTE E PAGAM O PREÇO.
Sempre que algo ocorre, seja no trabalho ou durante as aulas que ministro, sempre paro, respiro fundo e digo a mim mesmo: Eu amo problemas! Problemas me fazem crescer! Quer uma frase mais inspiradora que essa? "Problema bom é problema resolvido".
Se eu simplesmente te entregasse o ouro, como um belo índio de cabelos negros e lisos, você faria como os portugueses, iria embora sem nem me dar um espelho.
Ao invés disso vamos malhar o cérebro um pouco.
Quero que você entenda como ocorre esse filtro dos logs e para isso precisaremos inspecionar desde a requisição do navegador com o filtro, até o momento que o opnsense consulta as linhas do log e verifica se há uma correspondência do filtro ou não.
Abra as ferramentas de desenvolvedor do navegador (control+F12 ou control+shift+i) e clique na guia Rede.
Agora volte no campo de pesquisa e digite o nome do usuário da vpn + o termo de login bem sucedido: exemplo: [ludarkstar99] Peer Connection Initiated.
Você verá na guia de captura de requisições de rede, que houve uma requisição para a URL "/api/diagnostics/log/core/openvpn" e que foram passados alguns parametros searchPhrase e severity. SearchPhrase contém as palavras pesquisadas e severity os níveis de log para corresponder.
Agora, quando o servidor web recebe essa requisição, o código php vai rotear para uma controller que está associada a API.
Em específico, para sermos breve, será usado a controller "/usr/local/opnsense/mvc/app/controllers/OPNsense/Diagnostics/Api/LogController.php".

Você pode ver o código que remove os caracteres especiais na seguinte seção:
CodeSelect
// create filter to sanitize input data
        $filter = new Filter([
            'query' => function ($value) {
                return preg_replace("/[^0-9,a-z,A-Z, ,*,\-,_,.,\#,\:]/", "", $value);
            }
        ]);


Ou seja, só serão aceitos na pesquisa os caracteres: De a-z maiúsculas e minúsculas, números, e espaço.

Seguindo a lógico do código, essa função limita em 9999 a quantidade de linhas para não estourar a memória e em seguida chama o configd para executar a ação:
"system diag log" passando como parâmetros os termos de pesquisa, módulo (core), arquivo (openvpn) além das severities.

Bom, agora temos que saber o que o configd vai executar com esse comando, e agora vamos precisar consultar o arquivo "/usr/local/opnsense/service/conf/actions.d/actions_system.conf", no qual possui a definição da ação "diag log" conforme podemos ver abaixo.

CodeSelect
[diag.log]
command:/usr/local/opnsense/scripts/syslog/queryLog.py
parameters:--limit %s --offset %s --filter %s  --module %s --filename %s --severity %s
type:script_output
message:Show log

Pimba!

O configd está apenas chamando outro script (queryLog.py) e repassando os parâmetros para ele. Inclusive, podemos nós mesmos chamar o script python manualmente da seguinte forma:
CodeSelect
/usr/local/opnsense/scripts/syslog/queryLog.py --limit 10 --offset 0 --filter "ludarkstar99"  --module core --filename openvpn --severity ""

Pimba novamente!

A saída é um json contendo a linha do log com os metadados da pesquisa realizada:
CodeSelect
{"filters":"ludarkstar99","rows":[{"timestamp":"2025-02-20T00:15:39-03:00","parser":"SysLogFormatRFC5424","facility":3,"severity":"Notice","process_name":"openvpn_server4","pid":"703","rnum":3798,"line":" ludarkstar99\/177.177.177.177:64451 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt"},....
[...SAÍDA OMITIDA...]

Nadamos, nadamos... E ainda não descobrimos como é feito o filtro.
Calma jovem padawan, já estamos em 99% aqui. segue o baile.

Vamos abrir o arquivo que faz a consulta bruta ao log, /usr/local/opnsense/scripts/syslog/queryLog.py.

Aqui já podemos ver mais um pouco sobre o que representa cada argumento do script:
CodeSelect
if __name__ == '__main__':
    # handle parameters
    parser = argparse.ArgumentParser()
    parser.add_argument('--output', help='output type [json/text]', default='json')
    parser.add_argument('--filter', help='filter results', default='')
    parser.add_argument('--limit', help='limit number of results', default='')
    parser.add_argument('--offset', help='begin at row number', default='')
    parser.add_argument('--filename', help='log file name (excluding .log extension)', default='')
    parser.add_argument('--module', help='module', default='core')
    parser.add_argument('--severity', help='comma separated list of severities', default='')
    inputargs = parser.parse_args()


Logo mais abaixo vemos a lógica para abrir o(s) arquivo(s) de log.
CodeSelect
    if inputargs.filename != "":
        log_filenames = list()
        if inputargs.module == 'core':
            log_basename = "/var/log/%s" % os.path.basename(inputargs.filename)
        else:
            log_basename = "/var/log/%s/%s" % (
                os.path.basename(inputargs.module), os.path.basename(inputargs.filename)
            )
        if os.path.isdir(log_basename):
            # new syslog-ng local targets use an extra directory level
            filenames = glob.glob("%s/%s_*.log" % (log_basename, log_basename.split('/')[-1].split('.')[0]))
            for filename in sorted(filenames, reverse=True):
                log_filenames.append(filename)


Aqui temos o ouro, as linhas relacionadas a correpondencia do filtro no texto. Repare que é usado expressão regular.
O que acontece aqui é o seguinte:
1. Seu filtro de pesquisa tem o caractere * substituído por .* (expressão regular que identificar qualquer caractere 0 ou mais vezes;
2. Se não houver o caractere curinga na sua pesquisa (*), seu filtro vai ser forçado a virar uma expressão regular, com .* antes da(s) palavra(s) e depois;
3. O Script lê cada linha dos logs e verifica se a expressão regular corresponde com o texto da linha.

Aqui podemos ver as partes informadas acima:

CodeSelect
[...]
        try:
            filter = inputargs.filter.replace('*', '.*').lower()
            if filter.find('*') == -1:
                # no wildcard operator, assume partial match
                filter = ".*%s.*" % filter
            filter_regexp = re.compile(filter)
        except re.error:
            # remove illegal expression
            filter_regexp = re.compile('.*')

        row_number = 0
        for filename in log_filenames:
            if os.path.exists(filename):
                format_container = FormatContainer(filename)
                for rec in reverse_log_reader(filename):
                    row_number += 1
                    if rec['line'] != "" and filter_regexp.match(('%s' % rec['line']).lower()):
[...]

Detalhe sórdido que o script vai ler todos os arquivos da pasta /var/log/openvpn/* até atingir o limite de linhas (9999 caso não especificado).


Então podemos tirar as seguintes conclusões:
Para pesquisar na versão 24.7.2 ou anterior do opnsense, você pode usar o caractere curinga * sim, mas tem um formato especial para usá-lo.
Exemplo de filtro: *ludarkstar99*Peer Connection Initiated

Basicamente você coloca um * antes do texto, e um * entre palavras que há caracteres ou termos desconhecidos, então o curinga faz seu papel de curinga (wildcard).

E se você perguntar: luciano, não bastaria colocar ludarkstar*Peer ? tem mesmo que botar o * antes do texto? Tem sim meu jovem, isso ocorre por conta que antes do nome do usuário tem outros caracteres, como data/hora, nome do processo, e tal. Se a linha do log começasse com ludarkstar99, aí sim iria funcionar, mas não é assim que começa e você agora sabe exatamente o porque.


AS COISAS VELHAS JÁ PASSARAM, EIS QUE TUDO SE FEZ NOVO.
Certo. Entendemos o rolê que é fazer uma simples pesquisa no OPNsense 24.1, e aí eu fui tentar em outro firewall com a versão 24.7.12 e não deu certo...
Sabe porque não deu certo? Porque D'us quis! Talvez ele só ame quem lê e carrega seu código.

Mas se eu puder ajudar em algo, fica a dica, leia o código. As tábuas com os 10 mandamentos não foram feitas atoa...

A partir da versão 24.7.3 foi alterado o código que faz a correspondência de filtros no log.
Abrindo o mesmo arquivo /usr/local/opnsense/scripts/syslog/queryLog.py na versão 24.7, vemos que foi criado uma classe específica para esta função - LogMatcher conforme o trecho de código abaixo.

CodeSelect
[...]
from log_matcher import LogMatcher
[...]
log_matcher = LogMatcher(inputargs.filter, inputargs.filename, inputargs.module, inputargs.severity)
        for record in log_matcher.match_records():
[...]

Dá pra ver que alguém entendeu o domínio da questão e encapsulou a complexidade do código. E como ainda estamos em busca das tábuas perdidas, vamos precisar investigar abrindo o arquivo que contém a definição da classe LogMatcher.

Abrindo o arquivo /usr/local/opnsense/scripts/syslog/log_matcher.py podemos ver a implementação do filtro na versão 24.7, e a lógica ainda é a mesma. Checa se a linha tem correspondência via regex com o termo de pesquisa. Seu texto da caixinha de pesquisa é tratado como uma coisa só, por isso a necessidade de usar curingas (*) para dizer que tem algo entre as palavras pesquisadas.

CodeSelect 
    if line != "" and self.filter_regexp.match(('%s' % line).lower()):
        record = self.parse_line(line, format_container)
        if len(self.severity) == 0 or record['severity'] is None or record['severity'] in self.severity:
            yield record



Já na versão 24.7.3, podemos ver que foi completamente alterado a forma de pesquisar. Agora ao invés de usar a correspondência via expressão regular, passou a ser usado a função find (linha tmp.find abaixo) que nada mais é que uma busca por termos literais. Então nada de * mais nas pesquisas. Além disso, o código quebra cada palavra para pesquisá-la individualmente e só retorna correspondência se todos os tokens (palavras individuais) forem encontradas na linha do log.

CodeSelect

    def _match_line(self, line):
        # matcher, checks if all clauses are matched.
        tmp = line.lower()
        for clause in self.filter_clauses:
            if tmp.find(clause) == -1:
                return False

        return line != ''


Resumindo, até a versão 24.7.2 se fossemos pesquisar as conexões vpn para um determinado usuário, iríamos filtrar da seguinte forma:
filtro: "*ludarkstar99*Peer Connection Initiated".

A partir da versão 24.7.3, para pesquisar múltiplos termos na caixa de pesquisa, como no exemplo de usuário autenticado na vpn, ficariam assim:
filtro: "ludarkstar99 Peer Connection Initiated".

*sem as aspas é claro.
Lembrando que para a versão 24.7.3+ Só haverá resultado se todas as palavras forem encontradas dentro da linha do log.