"Recent posts
#1
Virtual private networks / Re: SOLVED - VERIFY ERROR: cou...
Last post by mcdeltat - Today at 01:58:37 AMThis can be marked as solved. I was of course following the docs for the new Instance Based "Road Warrior" setup, which can be found here: https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html
In there, the tiniest comment "Leaf Certificate - Type Server: Set the Common Name to the FQDN of this machine." bears all the weight here. You must set a CN value, no matter what it is, for things to work. I don't use a FQDN on my router yet, so I had omitted it. I put one that is a subdomain of my actual domain, but is not an actual DNS entry anywhere on my network. The other "Self-Signed Certificate Chains" doc also points to this, saying to put "leaf-certificate.example.com". See: https://docs.opnsense.org/manual/how-tos/self-signed-chain.html
Once I had reissued the certificate the OpenVPN instance was using, I restarted the instance from the Dashboard. I exported the ovpn client file again and imported.
RANT: Can we please get better warnings in OpnSense??!! I've been using it for 7+ years now and every single problem I have pulled my hair on can be chalked down to "UI does not clearly tell you what is a required field or warn you of obvious issues."
If modern OpenVPN/openssl implementations demand a CN, then it should either:
1) Be a required field when creating a new leaf certificate.
2) Flagged as a health status issue up top that says "Your OpenVPN instance certificate chain is missing a Common Name."
I'm tired boss. This took 5+ hours out of a good weekend. A tiny sentence, not in bold, not italicized, with no warnings from the router itself. That took 5 hours.
In there, the tiniest comment "Leaf Certificate - Type Server: Set the Common Name to the FQDN of this machine." bears all the weight here. You must set a CN value, no matter what it is, for things to work. I don't use a FQDN on my router yet, so I had omitted it. I put one that is a subdomain of my actual domain, but is not an actual DNS entry anywhere on my network. The other "Self-Signed Certificate Chains" doc also points to this, saying to put "leaf-certificate.example.com". See: https://docs.opnsense.org/manual/how-tos/self-signed-chain.html
Once I had reissued the certificate the OpenVPN instance was using, I restarted the instance from the Dashboard. I exported the ovpn client file again and imported.
RANT: Can we please get better warnings in OpnSense??!! I've been using it for 7+ years now and every single problem I have pulled my hair on can be chalked down to "UI does not clearly tell you what is a required field or warn you of obvious issues."
If modern OpenVPN/openssl implementations demand a CN, then it should either:
1) Be a required field when creating a new leaf certificate.
2) Flagged as a health status issue up top that says "Your OpenVPN instance certificate chain is missing a Common Name."
I'm tired boss. This took 5+ hours out of a good weekend. A tiny sentence, not in bold, not italicized, with no warnings from the router itself. That took 5 hours.
#2
German - Deutsch / Re: Hagezi DNS Listen & GitHub
Last post by JeGr - Today at 01:39:23 AMQuote from: trixter on August 20, 2026, 09:39:21 AMSchon bescheuert, da nutzt man freie unabhängige Software und doch tritt einem MS in den Arsch ;(
Naja bei vielen ist eben leider immer noch nicht angekommen, dass "Github = Microsoft" ist und sich der ganze Moloch dank Bruchpilot und Co in Zukunft nicht großartig verbessern, sondern eher verschlechtern (#enshitification) wird. Und nachdem die ursprünglichen Gründer/Betreiber jetzt von Bord und die Sparte ins Cloud/AI Gebimsel integriert wurde, wird das nur noch eine Frage der Zeit, bis wir das nächste "SourceForge" haben.
#3
26.7 Series / Transparent Filtering Bridge: ...
Last post by psehorne - September 06, 2026, 11:27:17 PMHello, group.
I did a search for an answer to my problem but did find any help.
I'm trying to set up newly installed OPNsense 26.7 (my first installation of OPNsense) as a transparent filtering bridge between my ISP and my router. I cannot access the GUI via my management port. I can access it via the LAN port, and both ports are configured the same except for the IP address.
The machine is a mini PC with two real Ethernet ports (LAN re0 and WAN re10). I added a USB Ethernet to us as the management port (MGMT ue0).
With the Ethernet cable from my PC connect to the LAN (re0) port I can access the GUI. With it connected to the MGMT (ue0) port I cannot access the GUI. (I have verified the USB Ethernet adapter works properly and that the Ethernet cables I am using are fine.)
There is a bridge also configured whose members include LAN, WAN, and MGMT.
The LAN port (192.168.1.35) and the MGMT port (192.168.1.36) both have an IP address. From the LAN port I can ping both IP addresses. From the MGMT port I cannot access the GUI, and pings from my PC timeout.
I have also tried giving the bridge an IP address (192.168.1.37). From the LAN port I could access the GUI and ping all three IP addresses. From the MGMT port I cannot ping any of the three address and cannot access the GUI.
Before I add any restrictive firewall rules, I have added firewall rules allowing packets from each port to pass unrestricted. This works. When I place the mini PC between my router and the ISP I can access the internet as expected. However without a working MGMT port I cannot administer the OPNsense instance.
Any ideas from the group as to how to configure this setup?
Thanks,
Paul
I did a search for an answer to my problem but did find any help.
I'm trying to set up newly installed OPNsense 26.7 (my first installation of OPNsense) as a transparent filtering bridge between my ISP and my router. I cannot access the GUI via my management port. I can access it via the LAN port, and both ports are configured the same except for the IP address.
The machine is a mini PC with two real Ethernet ports (LAN re0 and WAN re10). I added a USB Ethernet to us as the management port (MGMT ue0).
With the Ethernet cable from my PC connect to the LAN (re0) port I can access the GUI. With it connected to the MGMT (ue0) port I cannot access the GUI. (I have verified the USB Ethernet adapter works properly and that the Ethernet cables I am using are fine.)
There is a bridge also configured whose members include LAN, WAN, and MGMT.
The LAN port (192.168.1.35) and the MGMT port (192.168.1.36) both have an IP address. From the LAN port I can ping both IP addresses. From the MGMT port I cannot access the GUI, and pings from my PC timeout.
I have also tried giving the bridge an IP address (192.168.1.37). From the LAN port I could access the GUI and ping all three IP addresses. From the MGMT port I cannot ping any of the three address and cannot access the GUI.
Before I add any restrictive firewall rules, I have added firewall rules allowing packets from each port to pass unrestricted. This works. When I place the mini PC between my router and the ISP I can access the internet as expected. However without a working MGMT port I cannot administer the OPNsense instance.
Any ideas from the group as to how to configure this setup?
Thanks,
Paul
#4
Development and Code Review / Re: netflector available as pl...
Last post by UnicronHD - September 06, 2026, 11:10:53 PMQuote from: RamSense on September 03, 2026, 08:52:57 PMThat sounds like a sensible approach.
First implementation is ready. Which version of OPNsense are you running? Is it amd64 or arm64? Basically I need to know FreeBSD version and architecture to prepare a binary for you.
#5
26.7 Series / Re: Dashboard: Interface Stati...
Last post by sopex - September 06, 2026, 11:10:45 PMQuote from: vimage22 on September 06, 2026, 10:49:35 PMCould this be it?
https://github.com/opnsense/core/commit/b9a65b152eb155db4603b9318c99c599466b5d95
Unfortunately not. But I will have a look...
#6
26.7 Series / Re: Dashboard: Interface Stati...
Last post by vimage22 - September 06, 2026, 10:49:35 PM #7
26.7 Series / Re: Dashboard: Interface Stati...
Last post by vimage22 - September 06, 2026, 08:47:57 PMI followed all the links. But it seems to me this is still an open issue, right? For example:
"However, the interfaces widget still had a feedback loop due to the inserted scrollbar. Fix this by using borderBoxSize to determine width without overflow/scrollbar interference."
It seems like these patches should be in latest version, but not sure. So is this a work in progress?
In any event, thanks for supplying more context on this.
"However, the interfaces widget still had a feedback loop due to the inserted scrollbar. Fix this by using borderBoxSize to determine width without overflow/scrollbar interference."
It seems like these patches should be in latest version, but not sure. So is this a work in progress?
In any event, thanks for supplying more context on this.
#8
26.7 Series / Re: Caddy Layer4 Route TLS (SN...
Last post by ept - September 06, 2026, 08:20:55 PMThank you, that solves it!
(I have to admit that I even saw this PR, but didn't realize from the problem description that it fits to my issue.)
(I have to admit that I even saw this PR, but didn't realize from the problem description that it fits to my issue.)
#9
26.7 Series / Re: Dashboard: Interface Stati...
Last post by MoonbeamFrame - September 06, 2026, 08:13:26 PM #10
26.7 Series / Dashboard: Interface Statistic...
Last post by vimage22 - September 06, 2026, 07:57:35 PMVersion 26.7.3_11 (clean install)
After login, the Dashboard shows "Interface Statistics" with a very long vertical dimension. On the automatic refresh, it returns to normal, configured size. Is this a "Theme" issue, or something else?
After login, the Dashboard shows "Interface Statistics" with a very long vertical dimension. On the automatic refresh, it returns to normal, configured size. Is this a "Theme" issue, or something else?
