"Recent posts
#1
26.7 Series / Re: Interfaces: Virtual IPs: S...
Last post by notspam - Today at 10:18:21 PMThe problem is a bit the thread starter itself.
Without knowledge of basic network design rules all effort is in reality a waste of time.
It is important to seriously consider the issues and not just start building without a plan.
I have rarely read so many false things.
Without knowledge of basic network design rules all effort is in reality a waste of time.
It is important to seriously consider the issues and not just start building without a plan.
I have rarely read so many false things.
#2
26.7 Series / Re: os-upnp plugin not working...
Last post by BondiBlueBalls - Today at 09:46:38 PMOpened the feature request here: https://github.com/opnsense/plugins/issues/5674. Thanks again!
#3
General Discussion / Re: Why I am retiring from con...
Last post by muchacha_grande - Today at 09:45:50 PMUnbelievable... doesn't make any sense.
#4
German - Deutsch / Rtp Problem bei Sip Telefonie
Last post by Joeol - Today at 08:25:19 PMMoin, ich dachte ich guck hier mal rein, vielleicht hat noch jemand eine Idee für mich.
Problembeschreibung: Einseitige Audio-Verbindung bei Gigaset Go-Box 100 hinter OPNsense und IPTAM PBX
Ausgangslage & funktionierende Komponenten:
* Firewall: OPNsense (aktuelle Firmware)
* Telefonanlage: IPTAM PBX (hinter der OPNsense)
* IP-Telefon: Ein elmeg IP222 ist an der IPTAM angebunden und funktioniert einwandfrei (in beide Richtungen hörbar).
Das konkrete Problem:
Zusätzlich ist eine Gigaset Go-Box 100 an der IPTAM PBX registriert. Dabei tritt ein massiver Fehler im SIP-/RTP-Datenfluss auf (Einseitige Sprachverbindung / One-Way-Audio):
* Wenn die Go-Box Audiodaten von der IPTAM PBX empfängt, schickt sie diese nicht direkt an die IPTAM zurück.
* Stattdessen routet bzw. sendet die Go-Box die RTP-Pakete fälschlicherweise an die öffentliche WAN-IP-Adresse der OPNsense.
* Dort greifen die Firewall-Regeln (oder das NAT), die Pakete werden verworfen, und der Anrufer kann den Angerufenen folglich nicht hören.
Vermutung / Frage:
Es scheint sich um ein NAT-/Routing-Problem auf der Go-Box 100 oder eine fehlerhafte SIP-Registrierung/Port-Zuordnung in Kombination mit der OPNsense zu handeln.
* Wie kann ich der Go-Box 100 beibringen, die Audiodaten korrekt zur internen IPTAM PBX statt an die WAN-IP zu senden?
* Welche Einstellungen in der OPNsense (z. B. Outbound NAT, SIP-Helper/Stun) oder direkt in der Go-Box sind hierfür anzupassen?
Problembeschreibung: Einseitige Audio-Verbindung bei Gigaset Go-Box 100 hinter OPNsense und IPTAM PBX
Ausgangslage & funktionierende Komponenten:
* Firewall: OPNsense (aktuelle Firmware)
* Telefonanlage: IPTAM PBX (hinter der OPNsense)
* IP-Telefon: Ein elmeg IP222 ist an der IPTAM angebunden und funktioniert einwandfrei (in beide Richtungen hörbar).
Das konkrete Problem:
Zusätzlich ist eine Gigaset Go-Box 100 an der IPTAM PBX registriert. Dabei tritt ein massiver Fehler im SIP-/RTP-Datenfluss auf (Einseitige Sprachverbindung / One-Way-Audio):
* Wenn die Go-Box Audiodaten von der IPTAM PBX empfängt, schickt sie diese nicht direkt an die IPTAM zurück.
* Stattdessen routet bzw. sendet die Go-Box die RTP-Pakete fälschlicherweise an die öffentliche WAN-IP-Adresse der OPNsense.
* Dort greifen die Firewall-Regeln (oder das NAT), die Pakete werden verworfen, und der Anrufer kann den Angerufenen folglich nicht hören.
Vermutung / Frage:
Es scheint sich um ein NAT-/Routing-Problem auf der Go-Box 100 oder eine fehlerhafte SIP-Registrierung/Port-Zuordnung in Kombination mit der OPNsense zu handeln.
* Wie kann ich der Go-Box 100 beibringen, die Audiodaten korrekt zur internen IPTAM PBX statt an die WAN-IP zu senden?
* Welche Einstellungen in der OPNsense (z. B. Outbound NAT, SIP-Helper/Stun) oder direkt in der Go-Box sind hierfür anzupassen?
#5
26.7 Series / Re: Installed 26.7 - Trying to...
Last post by Pat.Ryan - Today at 07:03:56 PMFixed. I did not move to the development branch but rebuilt the community setup. Note that I did not have any luck reinstalling from the original image including reformatting the boot drive. The routine that did work was much faster and cleaned up everything.
What I had to do was rebuild from github and use the OPNsense-Bootstrap routine. This pulled the current 26.7.1.2 version and reinstalled the complete set including all the packages and plugins.
https://github.com/opnsense/update#opnsense-update-utilities
OPNsense update utilities
This is a collection of firmware upgrade tools specifically written for OPNsense based on FreeBSD ideas (kernel and base sets) and tools (pkg(8) and freebsd-update(8)).
opnsense-bootstrap
opnsense-bootstrap(8) is a tool that can completely reinstall a running system in place for a thorough factory reset or to restore consistency of all the OPNsense files. It can also wipe the configuration directory, but won't do that by default.
It will automatically pick up the latest available version and build a chain of trust by using current package fingerprints -> CA root certificates -> HTTPS -> OPNsense package fingerprints.
What it will also do is turn a supported stock FreeBSD release into an OPNsense installation. Both UFS and ZFS installations are supported.
The usage is simple, starting with a FreeBSD 15.1-RELEASE image:
# fetch https://raw.githubusercontent.com/opnsense/update/master/src/bootstrap/opnsense-bootstrap.sh.in
# sh ./opnsense-bootstrap.sh.in -r 26.7
What I had to do was rebuild from github and use the OPNsense-Bootstrap routine. This pulled the current 26.7.1.2 version and reinstalled the complete set including all the packages and plugins.
https://github.com/opnsense/update#opnsense-update-utilities
OPNsense update utilities
This is a collection of firmware upgrade tools specifically written for OPNsense based on FreeBSD ideas (kernel and base sets) and tools (pkg(8) and freebsd-update(8)).
opnsense-bootstrap
opnsense-bootstrap(8) is a tool that can completely reinstall a running system in place for a thorough factory reset or to restore consistency of all the OPNsense files. It can also wipe the configuration directory, but won't do that by default.
It will automatically pick up the latest available version and build a chain of trust by using current package fingerprints -> CA root certificates -> HTTPS -> OPNsense package fingerprints.
What it will also do is turn a supported stock FreeBSD release into an OPNsense installation. Both UFS and ZFS installations are supported.
The usage is simple, starting with a FreeBSD 15.1-RELEASE image:
# fetch https://raw.githubusercontent.com/opnsense/update/master/src/bootstrap/opnsense-bootstrap.sh.in
# sh ./opnsense-bootstrap.sh.in -r 26.7
#6
26.1, 26,4 Series / Re: How to delete a stale alia...
Last post by SmokeyJoe - Today at 07:00:32 PMI love you. So much.
Yes, disabling Automatic Discovery has cleaned the alias up. It's now showing exactly what it should.
Thank you!
Yes, disabling Automatic Discovery has cleaned the alias up. It's now showing exactly what it should.
Thank you!
#7
26.7 Series / Re: os-upnp plugin not working...
Last post by franco - Today at 06:57:26 PMSure, why not? If you can open a "feature request" on https://github.com/opnsense/plugins I can tag the user I mentioned and see what happens.
Cheers,
Franco
Cheers,
Franco
#8
26.1, 26,4 Series / Re: How to delete a stale alia...
Last post by Monviech (Cedrik) - Today at 06:48:55 PMCheck Interfaces - Neighbors - Automatic Discovery
If enabled the MAC address alias uses the database you find there.
If disabled then ARP is used.
If enabled the MAC address alias uses the database you find there.
If disabled then ARP is used.
#9
26.7 Series / Re: os-upnp plugin not working...
Last post by BondiBlueBalls - Today at 05:56:55 PMQuote from: franco on Today at 05:10:38 PMYes, I'd like to review and help shape the effort. But I have to say that I don't have a lot of time these days so this could be a longer effort.
The person who did the recent updates on the plugin and port was also open to this direction.
Eventually it has to be done either way as we aim to remove the static PHP pages within the next five years.
Cheers,
Franco
I'd be happy to help if an extra set of hands would be useful. 👍
#10
General Discussion / Beta testers and reviewers wan...
Last post by loredo - Today at 05:49:35 PMHi everyone,
I've built an independent open-source plugin that adds OpenID Connect sign-in to the OPNsense WebGUI. It has now entered public beta.
Three user-facing highlights:
- Unknown identities can enter an approval queue, where an administrator links them to an existing or new local account. The permanent binding uses the provider's exact issuer and stable subject identifier—not an email address or username—so ordinary changes such as a new surname or email address do not silently change the account association.
- You decide how much to trust the identity provider. Keep explicit administrator approval, automatically match existing users, or allow account creation on first login for a suitably controlled provider population.
- Authorization can remain entirely local, or selected local groups can be managed from an IdP group claim. Full group delegation is also possible, but requires an explicit choice.
The normal OPNsense password login remains available as a recovery path.
I built this for a single LAN-only firewall in my homelab, not for customers or as a commercial product. Development is heavily AI-assisted and backed by extensive automated tests, including generated browser screenshots. My capacity for feature requests will be limited.
I am primarily looking for help confirming real-world IdP compatibility and for independent review of the implementation, specifications and security assumptions. Automated tests are useful evidence, but not a substitute for expert review or a formal security audit.
Project and installation instructions:
https://github.com/jpawlowski/opnsense-openid-connect
Test reports, technical reviews and contributions would be very welcome.
I've built an independent open-source plugin that adds OpenID Connect sign-in to the OPNsense WebGUI. It has now entered public beta.
Three user-facing highlights:
- Unknown identities can enter an approval queue, where an administrator links them to an existing or new local account. The permanent binding uses the provider's exact issuer and stable subject identifier—not an email address or username—so ordinary changes such as a new surname or email address do not silently change the account association.
- You decide how much to trust the identity provider. Keep explicit administrator approval, automatically match existing users, or allow account creation on first login for a suitably controlled provider population.
- Authorization can remain entirely local, or selected local groups can be managed from an IdP group claim. Full group delegation is also possible, but requires an explicit choice.
The normal OPNsense password login remains available as a recovery path.
I built this for a single LAN-only firewall in my homelab, not for customers or as a commercial product. Development is heavily AI-assisted and backed by extensive automated tests, including generated browser screenshots. My capacity for feature requests will be limited.
I am primarily looking for help confirming real-world IdP compatibility and for independent review of the implementation, specifications and security assumptions. Automated tests are useful evidence, but not a substitute for expert review or a formal security audit.
Project and installation instructions:
https://github.com/jpawlowski/opnsense-openid-connect
Test reports, technical reviews and contributions would be very welcome.
