"Recent posts
#1
Portuguese - Português / [TUTORIAL] Como Configurar Ope...
Last post by TecDicas - Today at 01:47:14 AMOlá pessoal,
Publiquei um guia passo a passo detalhado sobre como configurar um servidor OpenVPN no OPNsense 26.7 a partir do zero.
Criei um LAB virtual com todos os detalhes
O foco principal deste tutorial é evitar o pesadelo administrativo de gerenciar dezenas de certificados individuais. Mostramos como montar uma arquitetura de Certificado Único Compartilhado perfeitamente integrada ao banco de dados local (Local Database). Dessa forma, você gera apenas um arquivo de configuração (.ovpn) para toda a equipe, mas mantém a segurança e a auditoria de logs individuais através da autenticação por usuário e senha.
Tópicos do artigo:
Controle de Acesso: Criação de Grupos restritos e Usuários locais.
Criptografia: Geração da Autoridade Certificadora (CA) e Certificados (Servidor/Cliente) de longo prazo.
Instância OpenVPN (26.7): Configuração completa na nova interface, ativando o Modo Avançado
Firewall: Criação das regras exatas de entrada na WAN (UDP 1194) e permissões de tráfego dentro do túnel.
Exportação e Teste: Geração do arquivo para OpenVPN Client
Troubleshooting: Um FAQ abordando cenários comuns, erros de "Timeout" e as diferenças práticas para o WireGuard em conexões Site-to-Site.
https://tecdicas.inf.br/configurar-openvpn-opnsense
Publiquei um guia passo a passo detalhado sobre como configurar um servidor OpenVPN no OPNsense 26.7 a partir do zero.
Criei um LAB virtual com todos os detalhes
O foco principal deste tutorial é evitar o pesadelo administrativo de gerenciar dezenas de certificados individuais. Mostramos como montar uma arquitetura de Certificado Único Compartilhado perfeitamente integrada ao banco de dados local (Local Database). Dessa forma, você gera apenas um arquivo de configuração (.ovpn) para toda a equipe, mas mantém a segurança e a auditoria de logs individuais através da autenticação por usuário e senha.
Tópicos do artigo:
Controle de Acesso: Criação de Grupos restritos e Usuários locais.
Criptografia: Geração da Autoridade Certificadora (CA) e Certificados (Servidor/Cliente) de longo prazo.
Instância OpenVPN (26.7): Configuração completa na nova interface, ativando o Modo Avançado
Firewall: Criação das regras exatas de entrada na WAN (UDP 1194) e permissões de tráfego dentro do túnel.
Exportação e Teste: Geração do arquivo para OpenVPN Client
Troubleshooting: Um FAQ abordando cenários comuns, erros de "Timeout" e as diferenças práticas para o WireGuard em conexões Site-to-Site.
https://tecdicas.inf.br/configurar-openvpn-opnsense
#2
German - Deutsch / Re: Client IPv6 Adressen und D...
Last post by AlexanderB - Today at 01:15:48 AMQuote from: Maurice on April 06, 2021, 02:40:01 AMDu hast zwei Möglichkeiten:
1. Tatsächlich auf jedem Host einen DynDNS-Client installieren.
2. Einen DynDNS-Dienst verwenden, der IPv6-Präfix-Updates unterstützt (z. B. dynv6.com). Dann muss OPNsense nur die Adresse seines LAN-Interfaces an den Dienst senden und der generiert mittels gespeicherter Interface Identifier die AAAA-Records für alle Hosts.
Denn das DynDNS-Plugin von OPNsense kann nur eine eigene IP-Adresse übertragen, nicht die eines Hosts im LAN. Dazu hatte ich mal einen Feature Request aufgemacht, wurde aber mangels Aktivität geschlossen (habe mich nicht mehr darum gekümmert):
https://github.com/opnsense/plugins/issues/1612
...
Die 2te Möglichkeit ist doch das, was Standard werden sollte, oder irre ich mich?
Die GUA Adressen in IPv6 sind doch genau dafür gemacht worden.
#3
Virtual private networks / Re: Self signed Certificate re...
Last post by zuma48 - Today at 12:45:53 AMHere is the auth, the 2024- with an end date is first then the one i JUST CREATED.
opnsense-internal-ca-2024 YES self-signed 129 emailAddress=p@X.com, ST=Florida, O=X, L=X, CN=internal-ca-2024, C=US
Valid From: Sun, 05 May 2024 21:36:22 +0000
Valid Until: Sat, 08 Aug 2026 21:36:22 +0000
Opensense-Certificate-2026-2029 YES self-signed 0 emailAddress=d@oX.com, ST=Florida, O=X, L=X, CN=internal-ca-2026-2029, C=US
Valid From: Tue, 28 Jul 2026 13:35:38 +0000
Valid Until: Mon, 30 Oct 2028 13:35:38 +0000
Did I not need to create this?
Under Certificates;
2025 Cert
CA: No, Server: Yes opnsense-internal-ca-2024 emailAddress=plove@omniadvertising.com, ST=Florida, O=Omni Advertising, L=Boca Raton, CN=server-cert-2024, C=US
Valid From: Tue, 18 Mar 2025 15:12:54 +0000
Valid Until: Fri, 16 Mar 2035 15:12:54 +0000
This was created...
opnsense-internal-ca-2024 YES self-signed 129 emailAddress=p@X.com, ST=Florida, O=X, L=X, CN=internal-ca-2024, C=US
Valid From: Sun, 05 May 2024 21:36:22 +0000
Valid Until: Sat, 08 Aug 2026 21:36:22 +0000
Opensense-Certificate-2026-2029 YES self-signed 0 emailAddress=d@oX.com, ST=Florida, O=X, L=X, CN=internal-ca-2026-2029, C=US
Valid From: Tue, 28 Jul 2026 13:35:38 +0000
Valid Until: Mon, 30 Oct 2028 13:35:38 +0000
Did I not need to create this?
Under Certificates;
2025 Cert
CA: No, Server: Yes opnsense-internal-ca-2024 emailAddress=plove@omniadvertising.com, ST=Florida, O=Omni Advertising, L=Boca Raton, CN=server-cert-2024, C=US
Valid From: Tue, 18 Mar 2025 15:12:54 +0000
Valid Until: Fri, 16 Mar 2035 15:12:54 +0000
This was created...
#4
General Discussion / Re: Help needed to update boot...
Last post by Patrick M. Hausen - July 29, 2026, 11:46:04 PMRelease candidate 3 vs. release. Simple as that. OPNsense 26.7 is based on 15.1 release so it contains a fixed boot loader.
IF you perform a fresh installation. If it's an update from 26.1 you will still have the old boot loader in the boot partitions, both EFI and legacy.
IF you perform a fresh installation. If it's an update from 26.1 you will still have the old boot loader in the boot partitions, both EFI and legacy.
#5
General Discussion / Re: Can't get firewall to pass...
Last post by thinkentropy - July 29, 2026, 11:44:14 PM<EDIT>
I took a look at my wiring today and I realized I had my computer (192.168.1.222) accidentally connected to both interfaces (LAN and VLANs) via a switch. That probably explains the asymmetric routing(!). But now that I removed my computer from the VLANs interface, my computer can't reach the truenas VM (192.168.3.248) at all.
My computer 192.168.1.222 can successfully ping 192.168.3.1.
The truenas VM 192.168.3.248 can successfully ping 192.168.1.1.
But 192.168.1.222 cannot talk to 192.168.3.248.
And whereas I was seeing block activity in the firewall live view before, now I'm not getting any, as though I broke the connection entirely. So, I don't even know where to go from here if the Opnsense firewall rules aren't to blame. I've also adjusted all of the networking-related knobs and dials within Proxmox that I am aware of to try and correct this.
At this point I believe this is a Proxmox VM configuration problem, and not anything with Opnsense. So I don't expect anyone here to help troubleshoot Proxmox. Unless anyone has any suggestions to try, I am very reluctantly moving everything back to bare metal this weekend.
Thank you again to everyone that has offered suggestions up to this point!
<EDIT 2>
For grins I just tried connecting both of the network ports into a switch and now things behave the way I would expect them to. My computer on 192.168.1.222 can reach the truenas gui at 192.168.3.248. I can also create firewall rules in Opnsense that pass or block traffic the way I would expect them to. I am obviously new to networking, so possibly I fundamentally misunderstand how routers help facilitate the movement of traffic through subnets.
Each of the physical network interfaces on my machine have their own separate multiport switch. I did that so I could segregate all of my devices--e.g. webcams would all connect to one switch (and hence one network interface), all MAIN LAN devices connect to another switch (and hence a second network interface), and so on. In that configuration I assumed all of the subnet traffic would have to pass THROUGH the router. That's how I previously had everything setup when I had Opnsense running on bare metal and it seemed to work just fine.
Now, it appears as though I need the two network interfaces plugged into the same switch to pass subnet traffic. I guess I'll have to just more reading, and I'll keep playing with it for the next few days and see if I can better understand what is happening.
I took a look at my wiring today and I realized I had my computer (192.168.1.222) accidentally connected to both interfaces (LAN and VLANs) via a switch. That probably explains the asymmetric routing(!). But now that I removed my computer from the VLANs interface, my computer can't reach the truenas VM (192.168.3.248) at all.
My computer 192.168.1.222 can successfully ping 192.168.3.1.
The truenas VM 192.168.3.248 can successfully ping 192.168.1.1.
But 192.168.1.222 cannot talk to 192.168.3.248.
And whereas I was seeing block activity in the firewall live view before, now I'm not getting any, as though I broke the connection entirely. So, I don't even know where to go from here if the Opnsense firewall rules aren't to blame. I've also adjusted all of the networking-related knobs and dials within Proxmox that I am aware of to try and correct this.
At this point I believe this is a Proxmox VM configuration problem, and not anything with Opnsense. So I don't expect anyone here to help troubleshoot Proxmox. Unless anyone has any suggestions to try, I am very reluctantly moving everything back to bare metal this weekend.
Thank you again to everyone that has offered suggestions up to this point!
<EDIT 2>
For grins I just tried connecting both of the network ports into a switch and now things behave the way I would expect them to. My computer on 192.168.1.222 can reach the truenas gui at 192.168.3.248. I can also create firewall rules in Opnsense that pass or block traffic the way I would expect them to. I am obviously new to networking, so possibly I fundamentally misunderstand how routers help facilitate the movement of traffic through subnets.
Each of the physical network interfaces on my machine have their own separate multiport switch. I did that so I could segregate all of my devices--e.g. webcams would all connect to one switch (and hence one network interface), all MAIN LAN devices connect to another switch (and hence a second network interface), and so on. In that configuration I assumed all of the subnet traffic would have to pass THROUGH the router. That's how I previously had everything setup when I had Opnsense running on bare metal and it seemed to work just fine.
Now, it appears as though I need the two network interfaces plugged into the same switch to pass subnet traffic. I guess I'll have to just more reading, and I'll keep playing with it for the next few days and see if I can better understand what is happening.
#6
General Discussion / Re: Help needed to update boot...
Last post by BrandyWine - July 29, 2026, 11:33:08 PMQuote from: nero355 on July 29, 2026, 04:44:04 PM15.1 Release is June 16th (a lie on their site, https://www.freebsd.org/releases/)Quote from: BrandyWine on July 28, 2026, 08:50:31 PMmake the OPNsense 26.7.2 version with 15.1-rc3Dude... you know 15.1 is newer than the RC3 release for 15.1 right ?!
And again : The problem are FreeBSD 14.x to 15.x upgrades and not fresh installs of FreeBSD 15.x a.k.a. OPNsense 26.7.x :)
15.1 is actually June 12th (https://download.freebsd.org/releases/amd64/15.1-RELEASE/)
RC3 is June 6th.
What's the diff?
#7
Web Proxy Filtering and Caching / Re: postfix service run into t...
Last post by Igor - July 29, 2026, 10:16:42 PMThe 300s timeout is Postfix's `milter_content_timeout` default, so the chain you describe is plausible — but IPv6 loopback isn't inherently slow, so something is dropping the traffic. Could you check a few things?
1. Is Redis actually listening on `::1`? `sockstat -6 | grep 6379` — and what does `bind` say in your redis.conf?
2. If it isn't listening there, you'd expect an instant connection refused rather than a delay. A delay that grows on retries (roughly 1s, 3s, 7s) is the signature of SYN packets being silently dropped.
3. Do you have any rule blocking IPv6, or any floating rule that isn't scoped away from `lo0`? Try `pfctl -s rules | grep lo0`, and enable logging on your block rules to see whether loopback IPv6 is being dropped.
4. What does `redis-cli -h ::1 -p 6379 --latency` show versus the same on 127.0.0.1?
As a workaround you can pin rspamd to IPv4 with `servers = "127.0.0.1:6379";` in `/usr/local/etc/rspamd/local.d/redis.conf` — there's no GUI option for it. But that's masking the symptom; the firewall rule is worth finding.
#8
Web Proxy Filtering and Caching / Re: Access Lists: support dyna...
Last post by Monviech (Cedrik) - July 29, 2026, 09:55:37 PMDiscussed it here a while ago and not planning to do it.
https://github.com/opnsense/plugins/issues/5358
https://github.com/opnsense/plugins/issues/5358
#9
General Discussion / Re: Firewall aliases #Loaded v...
Last post by keeka - July 29, 2026, 09:03:42 PMThe example alias I gave is referenced in a destination NAT rule, a corresponding (unlinked/manual) firewall rule, and also in another firewall rule. All configured on WAN interface only.
#10
Web Proxy Filtering and Caching / Access Lists: support dynamic/...
Last post by dinguz - July 29, 2026, 09:01:14 PMIn Firewall > Aliases you can create a "URL Table (IPs)" alias that periodically re-fetches its contents from a remote source (e.g. Cloudflare's official IP ranges), so the alias stays current without manual maintenance.
The Caddy plugin's Access Lists (Services > Caddy > Access) only support static, manually entered CIDR blocks. For something like a Cloudflare IP list, this means every range change on Cloudflare's end has to be applied by hand, otherwise the list silently drifts out of sync.
Would it be possible to either:
so lists like this stay in sync automatically instead of requiring manual upkeep?
The Caddy plugin's Access Lists (Services > Caddy > Access) only support static, manually entered CIDR blocks. For something like a Cloudflare IP list, this means every range change on Cloudflare's end has to be applied by hand, otherwise the list silently drifts out of sync.
Would it be possible to either:
- let an Access List reference an existing Firewall alias, or
- give Access Lists their own periodic remote-fetch option, similar to URL Table aliases
so lists like this stay in sync automatically instead of requiring manual upkeep?
