"Recent posts
#1
26.1, 26,4 Series / Re: noob here, TLS unbound iss...
Last post by matthewacbroad - Today at 01:06:45 PMhave reached the point where I'm hoping someone familiar with pf or FreeBSD networking can point me in the right direction.
Topology
Internet
│
Rogers XB6 (Technicolor CGM4140COM)
DMZ → OPNsense WAN (10.0.0.247 via DHCP)
│
OPNsense
│
LAN
│
Single Linux laptop
The Rogers gateway is configured to place my OPNsense WAN IP (10.0.0.247) in the DMZ with reserved IP.
Symptoms
DNS resolution works.
TCP connection establishes successfully.
curl https://wikipedia.org hangs immediately after sending the TLS ClientHello.
openssl s_client also connects but never receives a ServerHello.
The same behavior occurs with multiple sites.
Example:
curl -4 -v https://wikipedia.org
* Host wikipedia.org:443 was resolved.
* Trying 198.35.26.224:443...
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
It never progresses beyond that point.
openssl s_client shows:
Connecting to 198.35.26.224
CONNECTED(00000003)
and then waits indefinitely.
Things I've already checked
MTU path tested with ping -M do and large packets succeed.
Disabled IDS/IPS completely.
Disabled hardware offloading.
Cleared firewall states.
WAN MTU override issue was corrected (I had accidentally enabled "Override MTU" on the DHCP client previously).
DNS works correctly.
Packet capture
Packet captures on both the WAN and LAN interfaces while reproducing the problem.
The interesting observation was:
The WAN interface showed the TLS connection attempt.
The LAN interface did not show the expected traffic for that same connection.
I'm not sure whether this indicates I captured on the wrong interface, whether hardware/driver behavior is affecting the capture, or whether it suggests something about how the traffic is being processed.
Topology
Internet
│
Rogers XB6 (Technicolor CGM4140COM)
DMZ → OPNsense WAN (10.0.0.247 via DHCP)
│
OPNsense
│
LAN
│
Single Linux laptop
The Rogers gateway is configured to place my OPNsense WAN IP (10.0.0.247) in the DMZ with reserved IP.
Symptoms
DNS resolution works.
TCP connection establishes successfully.
curl https://wikipedia.org hangs immediately after sending the TLS ClientHello.
openssl s_client also connects but never receives a ServerHello.
The same behavior occurs with multiple sites.
Example:
curl -4 -v https://wikipedia.org
* Host wikipedia.org:443 was resolved.
* Trying 198.35.26.224:443...
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
It never progresses beyond that point.
openssl s_client shows:
Connecting to 198.35.26.224
CONNECTED(00000003)
and then waits indefinitely.
Things I've already checked
MTU path tested with ping -M do and large packets succeed.
Disabled IDS/IPS completely.
Disabled hardware offloading.
Cleared firewall states.
WAN MTU override issue was corrected (I had accidentally enabled "Override MTU" on the DHCP client previously).
DNS works correctly.
Packet capture
Packet captures on both the WAN and LAN interfaces while reproducing the problem.
The interesting observation was:
The WAN interface showed the TLS connection attempt.
The LAN interface did not show the expected traffic for that same connection.
I'm not sure whether this indicates I captured on the wrong interface, whether hardware/driver behavior is affecting the capture, or whether it suggests something about how the traffic is being processed.
#2
Tutorials and FAQs / Re: What to do and what to avo...
Last post by Patrick M. Hausen - Today at 12:28:46 PMI'm fine with 825 days and warnings from Uptime Kuma. Of course automation will take care of all the public ones.
I'm planning to get some beer and popcorn ready when our enterprise customers' IT departments finally notice the 47 day change. 😬 I don't understand why so many insist to send us their "official" certs for their web sites instead of switching on ACME which we include free of charge in our hosting platform in the form of Dehydrated.
I'm planning to get some beer and popcorn ready when our enterprise customers' IT departments finally notice the 47 day change. 😬 I don't understand why so many insist to send us their "official" certs for their web sites instead of switching on ACME which we include free of charge in our hosting platform in the form of Dehydrated.
#3
Tutorials and FAQs / Re: What to do and what to avo...
Last post by meyergru - Today at 12:22:00 PMQuote from: newsense on Today at 11:09:21 AMActually I think @meyergru forgot we're already down to 199 days for public certificates and come next March the value will be 100 days, and 45 days in another year.
What I wanted to stress is the fact that you cannot use your own long-lived certificates unless you use a trick that OpnSense has not got under its sleeve (maybe that would be a good feature request): namely, you cannot set the start date of an issued certificate to "-startdate 20190630120000Z", which I always do with my own CA. This is because "old" certificates can last arbitrarily long. I tend to issue them for at least 10 years, which is way longer than 825, 397, 199, 100 or even 47 days - and 10 years definitely does not work when the "Not Before" date is not manipulated. I changed my CA script to use that "Not Before" date and never looked back because that eliminates the need to ever think about this again ("i.e. "have your cake and eat it").
On the other hand, it simply does not matter how long ACME certificates can last, just because OpnSense can (and will) also reissue them at the respective appropriate intervals, even when the duration changes in the future.
I updated the guide to make this even more obvious.
#4
Portuguese - Português / Failover dual-WAN automático e...
Last post by Nuno - Today at 11:32:01 AMFailover dual-WAN automático em OPNsense (fibra + 5G)
Uma só ligação à internet é um ponto único de falha. Basta uma quebra a meio de uma
chamada, de um upload ou de um exame online e ficamos presos a reconectar à mão. Por isso
montei uma segunda ligação que assume sozinha: fibra como linha principal, 5G como recurso.
Quando a fibra cai, o tráfego passa para o 5G em segundos; quando a fibra volta, regressa a
ela.
Isto é failover puro, não load balancing — uma linha leva tudo, a outra espera. Fica
aqui a configuração completa. Parte do princípio de que as duas WAN já estão definidas como
interfaces (no meu caso: fibra na WAN, 5G na OPT1).
1) Gateways — System ▸ Gateways ▸ Configuration
Dá a cada gateway um monitor IP distinto e externo. É isto que faz o failover
disparar de verdade. Eu uso:
- fibra → 1.1.1.1
- 5G → 8.8.8.8
Mantém o gateway monitoring ativo. Sem monitor IPs distintos, o OPNsense não percebe que uma
linha caiu, e o failover nunca acontece.
2) Gateway group — System ▸ Gateways ▸ Group ▸ Add
- Nome: GW_FAILOVER
- Fibra = Tier 1
- 5G = Tier 2
- Trigger Level: Member down
"Member down" significa que só salta para o 5G quando o gateway da fibra é dado como morto —
exatamente o que se quer para uma separação limpa entre principal e recurso.
3) A regra de LAN — Firewall ▸ Rules ▸ LAN (o passo que a maioria dos guias esquece)
Edita a regra "allow LAN to any" (ou cria uma nova no topo). Em Advanced, define:
- Gateway → GW_FAILOVER
É este o passo que ativa o policy-based routing. Sem ele, o tráfego da LAN ignora o grupo
por completo e o failover não faz nada. Se houver uma coisa para reter deste post, é esta.
4) Outbound NAT — Firewall ▸ NAT ▸ Outbound
O modo automático já cobre as duas interfaces. Se usares Hybrid/Manual, garante que existe
regra de outbound NAT para a fibra e para o 5G, senão o tráfego pelo recurso não é
traduzido.
5) DNS
O Unbound local resolve sem problema. Se reencaminhares para o resolver do ISP, muda-o para
1.1.1.1 / 8.8.8.8 em System ▸ Settings ▸ General, para não ficares preso ao DNS da fibra
quando a fibra é precisamente o que está em baixo.
Testar — a sério
Não confies nisto sem o partires primeiro. Desliga a fibra fisicamente e cronometra a
comutação. Com "Member down", conta com uns 5–10 segundos até o 5G assumir. Volta a ligar e
confirma que regressa à fibra.
O que sobrevive à troca (e o que não)
A comutação demora uns segundos, e as sessões TCP ativas quebram — a ligação cai e
restabelece-se no novo caminho. Tudo aquilo em que a sessão vive num token e não no IP (a
maioria das apps web em HTTPS) aguenta um recarregar de página sem perder o estado. Streams
de longa duração levam com o corte. Planeia em conformidade.
Notas
- O 5G atrás de CGNAT não é problema aqui: não são precisas ligações de entrada, isto é
failover de saída.
- Sê honesto quanto ao alcance: isto é failover por queda de link, não SD-WAN. Não
há seleção de caminho em tempo real por latência/jitter/perda nem orquestração central —
comuta quando um link é dado como morto, que é o que a maioria dos homelabs e pequenos
escritórios precisa.
Nota de hardware: corri isto num appliance de segunda mão, fanless, sem saída de vídeo
(instalação só por consola série), mas a configuração de failover acima é igual em qualquer
máquina compatível com OPNsense.
Disponível para responder a dúvidas — e se puxares mesmo o cabo para testar, diz-me o teu
tempo de comutação. :)
Uma só ligação à internet é um ponto único de falha. Basta uma quebra a meio de uma
chamada, de um upload ou de um exame online e ficamos presos a reconectar à mão. Por isso
montei uma segunda ligação que assume sozinha: fibra como linha principal, 5G como recurso.
Quando a fibra cai, o tráfego passa para o 5G em segundos; quando a fibra volta, regressa a
ela.
Isto é failover puro, não load balancing — uma linha leva tudo, a outra espera. Fica
aqui a configuração completa. Parte do princípio de que as duas WAN já estão definidas como
interfaces (no meu caso: fibra na WAN, 5G na OPT1).
1) Gateways — System ▸ Gateways ▸ Configuration
Dá a cada gateway um monitor IP distinto e externo. É isto que faz o failover
disparar de verdade. Eu uso:
- fibra → 1.1.1.1
- 5G → 8.8.8.8
Mantém o gateway monitoring ativo. Sem monitor IPs distintos, o OPNsense não percebe que uma
linha caiu, e o failover nunca acontece.
2) Gateway group — System ▸ Gateways ▸ Group ▸ Add
- Nome: GW_FAILOVER
- Fibra = Tier 1
- 5G = Tier 2
- Trigger Level: Member down
"Member down" significa que só salta para o 5G quando o gateway da fibra é dado como morto —
exatamente o que se quer para uma separação limpa entre principal e recurso.
3) A regra de LAN — Firewall ▸ Rules ▸ LAN (o passo que a maioria dos guias esquece)
Edita a regra "allow LAN to any" (ou cria uma nova no topo). Em Advanced, define:
- Gateway → GW_FAILOVER
É este o passo que ativa o policy-based routing. Sem ele, o tráfego da LAN ignora o grupo
por completo e o failover não faz nada. Se houver uma coisa para reter deste post, é esta.
4) Outbound NAT — Firewall ▸ NAT ▸ Outbound
O modo automático já cobre as duas interfaces. Se usares Hybrid/Manual, garante que existe
regra de outbound NAT para a fibra e para o 5G, senão o tráfego pelo recurso não é
traduzido.
5) DNS
O Unbound local resolve sem problema. Se reencaminhares para o resolver do ISP, muda-o para
1.1.1.1 / 8.8.8.8 em System ▸ Settings ▸ General, para não ficares preso ao DNS da fibra
quando a fibra é precisamente o que está em baixo.
Testar — a sério
Não confies nisto sem o partires primeiro. Desliga a fibra fisicamente e cronometra a
comutação. Com "Member down", conta com uns 5–10 segundos até o 5G assumir. Volta a ligar e
confirma que regressa à fibra.
O que sobrevive à troca (e o que não)
A comutação demora uns segundos, e as sessões TCP ativas quebram — a ligação cai e
restabelece-se no novo caminho. Tudo aquilo em que a sessão vive num token e não no IP (a
maioria das apps web em HTTPS) aguenta um recarregar de página sem perder o estado. Streams
de longa duração levam com o corte. Planeia em conformidade.
Notas
- O 5G atrás de CGNAT não é problema aqui: não são precisas ligações de entrada, isto é
failover de saída.
- Sê honesto quanto ao alcance: isto é failover por queda de link, não SD-WAN. Não
há seleção de caminho em tempo real por latência/jitter/perda nem orquestração central —
comuta quando um link é dado como morto, que é o que a maioria dos homelabs e pequenos
escritórios precisa.
Nota de hardware: corri isto num appliance de segunda mão, fanless, sem saída de vídeo
(instalação só por consola série), mas a configuração de failover acima é igual em qualquer
máquina compatível com OPNsense.
Disponível para responder a dúvidas — e se puxares mesmo o cabo para testar, diz-me o teu
tempo de comutação. :)
#5
Tutorials and FAQs / Automatic dual-WAN failover on...
Last post by Nuno - Today at 11:28:15 AMAutomatic dual-WAN failover on OPNsense (fibre + 5G)
A single internet line is a single point of failure. One outage mid-call, mid-upload, or
mid-exam and you're stuck reconnecting by hand. So I set up a second line that takes over
on its own: fibre as the primary link, 5G as the backup. When fibre dies, traffic moves to
5G in seconds; when fibre comes back, it switches back.
This is pure failover, not load balancing — one line carries everything, the other
waits. Here's the full setup. It assumes both WANs are already configured as interfaces
(mine: fibre on WAN, 5G on OPT1).
1) Gateways — System ▸ Gateways ▸ Configuration
Give each gateway a distinct, external monitor IP. This is what makes failover
actually trigger. I use:
- fibre → 1.1.1.1
- 5G → 8.8.8.8
Keep gateway monitoring enabled. Without separate monitor IPs, OPNsense can't tell that
one link is down, and the failover never fires.
2) Gateway group — System ▸ Gateways ▸ Group ▸ Add
- Name: GW_FAILOVER
- Fibre = Tier 1
- 5G = Tier 2
- Trigger Level: Member down
"Member down" means it only jumps to 5G once the fibre gateway is declared dead — exactly
what you want for a clean primary/backup split.
3) The LAN rule — Firewall ▸ Rules ▸ LAN (the step most guides forget)
Edit your "allow LAN to any" rule (or add one at the top). In Advanced, set:
- Gateway → GW_FAILOVER
This is the step that activates policy-based routing. Without it, your LAN traffic ignores
the group entirely and the failover does nothing. If you take one thing from this post,
take this.
4) Outbound NAT — Firewall ▸ NAT ▸ Outbound
Automatic mode already covers both interfaces. If you run Hybrid/Manual, make sure there's
an outbound NAT rule for both fibre and 5G, or traffic over the backup won't be
translated.
5) DNS
Local Unbound resolves fine. If you forward to your ISP's resolver, switch it to 1.1.1.1 /
8.8.8.8 in System ▸ Settings ▸ General, so you don't stay tied to the fibre's DNS when the
fibre is the thing that's down.
Testing it — for real
Don't trust it until you've broken it. Physically unplug the fibre and time the cutover.
With "Member down", expect roughly 5–10 seconds before 5G takes over. Plug it back in and
confirm it returns to fibre.
What survives the switch (and what doesn't)
The cutover is a few seconds, and active TCP sessions break — the connection drops and
re-establishes on the new path. Anything where the session lives in a token rather than the
IP (most HTTPS web apps) survives a page reload without losing state. Long-lived streams
take the hit. Plan accordingly.
Notes
- 5G behind CGNAT is fine here: no inbound connections needed, this is outbound failover.
- Be honest about scope: this is link-down failover, not SD-WAN. There's no
real-time path selection by latency/jitter/loss and no central orchestration — it
switches when a link is declared down, which is what most homelabs and small offices
actually need.
Hardware note: I ran this on a second-hand, fanless appliance with no video output
(serial-console install only), but the failover config above is identical on any
OPNsense-compatible box.
Happy to answer questions — and if you genuinely pull the cable to test, tell me your
cutover time. :)
A single internet line is a single point of failure. One outage mid-call, mid-upload, or
mid-exam and you're stuck reconnecting by hand. So I set up a second line that takes over
on its own: fibre as the primary link, 5G as the backup. When fibre dies, traffic moves to
5G in seconds; when fibre comes back, it switches back.
This is pure failover, not load balancing — one line carries everything, the other
waits. Here's the full setup. It assumes both WANs are already configured as interfaces
(mine: fibre on WAN, 5G on OPT1).
1) Gateways — System ▸ Gateways ▸ Configuration
Give each gateway a distinct, external monitor IP. This is what makes failover
actually trigger. I use:
- fibre → 1.1.1.1
- 5G → 8.8.8.8
Keep gateway monitoring enabled. Without separate monitor IPs, OPNsense can't tell that
one link is down, and the failover never fires.
2) Gateway group — System ▸ Gateways ▸ Group ▸ Add
- Name: GW_FAILOVER
- Fibre = Tier 1
- 5G = Tier 2
- Trigger Level: Member down
"Member down" means it only jumps to 5G once the fibre gateway is declared dead — exactly
what you want for a clean primary/backup split.
3) The LAN rule — Firewall ▸ Rules ▸ LAN (the step most guides forget)
Edit your "allow LAN to any" rule (or add one at the top). In Advanced, set:
- Gateway → GW_FAILOVER
This is the step that activates policy-based routing. Without it, your LAN traffic ignores
the group entirely and the failover does nothing. If you take one thing from this post,
take this.
4) Outbound NAT — Firewall ▸ NAT ▸ Outbound
Automatic mode already covers both interfaces. If you run Hybrid/Manual, make sure there's
an outbound NAT rule for both fibre and 5G, or traffic over the backup won't be
translated.
5) DNS
Local Unbound resolves fine. If you forward to your ISP's resolver, switch it to 1.1.1.1 /
8.8.8.8 in System ▸ Settings ▸ General, so you don't stay tied to the fibre's DNS when the
fibre is the thing that's down.
Testing it — for real
Don't trust it until you've broken it. Physically unplug the fibre and time the cutover.
With "Member down", expect roughly 5–10 seconds before 5G takes over. Plug it back in and
confirm it returns to fibre.
What survives the switch (and what doesn't)
The cutover is a few seconds, and active TCP sessions break — the connection drops and
re-establishes on the new path. Anything where the session lives in a token rather than the
IP (most HTTPS web apps) survives a page reload without losing state. Long-lived streams
take the hit. Plan accordingly.
Notes
- 5G behind CGNAT is fine here: no inbound connections needed, this is outbound failover.
- Be honest about scope: this is link-down failover, not SD-WAN. There's no
real-time path selection by latency/jitter/loss and no central orchestration — it
switches when a link is declared down, which is what most homelabs and small offices
actually need.
Hardware note: I ran this on a second-hand, fanless appliance with no video output
(serial-console install only), but the failover config above is identical on any
OPNsense-compatible box.
Happy to answer questions — and if you genuinely pull the cable to test, tell me your
cutover time. :)
#6
Tutorials and FAQs / Re: What to do and what to avo...
Last post by Patrick M. Hausen - Today at 11:23:29 AMQuote from: newsense on Today at 11:09:21 AMCreate those certificates with 730 days validity and they will work fine until Apple or some other big player decides arbitrarily to reduce that number.
I guess that this number is 825, really. That's based on my own research and tests for browser certificates.
Theoretically private CAs and certs can have arbitrarily long lifetimes. And e.g. Windows will respect that. When in 2018 the browser consortium decided to lower the maximum for public certs to 825 days Apple messed it up and limited the lifetime for all certs including private ones.
When the next round of lifetime cuts happened in 2020 the limit for public ones was reduced to 397 days. Luckily this time Apple did not touch the maximum for private certs.
So to the best of my knowledge today the situation is as follows:
- Public CA: 200 days since March 2026 (used to be 397), 100 days from March 2027, 47 days from March 2029
- Private CA: arbitrary for most platforms, 825 days for Apple.
I might be wrong about the 730 vs. 825 days value in the specific case of IPsec, I have only tested browsers, not certificate based VPNs.
Our company OpenVPN uses certs issued by a private CA with 10 years of cert lifetime without problems. Of course we have additional strong password authentication per user.
HTH,
Patrick
#7
26.1, 26,4 Series / Re: Import rules [new] dialog ...
Last post by tz-mbc - Today at 11:13:28 AMThis is strange indeed. My dialog is just sitting there for more than an hour with checkbox activated.
I find this whole process a bit confusing to be honest. When I enter the New rules page all my "old" rules are already showing and the Apply button is active. Which made me think that maybe this new release migrated the rules automatically but not activated them yet, and all I need to do is to hit Apply and deactivate the old rules...bad idea...but my backup was working :-)
I meanwhile found out that it shows the old rules in the new rule section, because when I deactivate a rule in old, it disappears in new.
I find this whole process a bit confusing to be honest. When I enter the New rules page all my "old" rules are already showing and the Apply button is active. Which made me think that maybe this new release migrated the rules automatically but not activated them yet, and all I need to do is to hit Apply and deactivate the old rules...bad idea...but my backup was working :-)
I meanwhile found out that it shows the old rules in the new rule section, because when I deactivate a rule in old, it disappears in new.
#8
Tutorials and FAQs / Re: What to do and what to avo...
Last post by newsense - Today at 11:09:21 AMActually I think @meyergru forgot we're already down to 199 days for public certificates and come next March the value will be 100 days, and 45 days in another year.
Until we get hybrid certificates there's literally no justification for having to tinker with certificates every so often on your own vpn.
They're doing it to reduce costs mainly in the public space, and also to increase revenue by selling you certificate lifecycle management services now that LetsEncrypt destroyed their highly lucrative business of selling EV certificates as if they would have provided better security than OV or DV ones.
In a nutshell, you'll need the root on the devices you'll use for IPsec ( or any other place you use certificates issued by your own CA ). Create those certificates with 730 days validity and they will work fine until Apple or some other big player decides arbitrarily to reduce that number.
Until we get hybrid certificates there's literally no justification for having to tinker with certificates every so often on your own vpn.
They're doing it to reduce costs mainly in the public space, and also to increase revenue by selling you certificate lifecycle management services now that LetsEncrypt destroyed their highly lucrative business of selling EV certificates as if they would have provided better security than OV or DV ones.
In a nutshell, you'll need the root on the devices you'll use for IPsec ( or any other place you use certificates issued by your own CA ). Create those certificates with 730 days validity and they will work fine until Apple or some other big player decides arbitrarily to reduce that number.
#9
26.1, 26,4 Series / Re: Import rules [new] dialog ...
Last post by dseven - Today at 10:54:26 AMFor me, on clicking that, the rules from the CSV file appear in the UI, and I'm prompted "After changing settings, please remember to apply them." (as you would after any rules change).
#10
26.1, 26,4 Series / Re: 26.1.7_2: issue with ACME ...
Last post by Creat - Today at 10:42:47 AMQuote from: fragrance744 on June 23, 2026, 07:34:55 AMmidclt, https://github.com/truenas/api_client, is required for using TrueNAS websocket API.
The script may work after installing it.
I'm sorry but that makes no sense. This has already worked after I had swapped the automation to the new websocket API, it just stopped working at some point. How could it have worked if that tool is needed?
Also, midclt isn't what you linked on github. You linked to a script that calls `midclt` LOCALLY, which in turn is present by default on any TrueNAS install. The whole point of a (websocket) API is that you don't need to install anything locally to use it. And installing it locally doesn't seem possible (as it supposedly talks to a local truenas install). Even then, there's NO chance I'm installing `midclt` on my firewall as that wouldn't survive a config backp/restore AND this is the firs thing the GitHub page says: Software in ALPHA state, highly experimental.
