Messages

Sorry, my notifications are disabled in the forum, so I didn't see your message.
I run this patch with the following command...

Code Select Expand

patch --directory=/ -p0 < radiusv3.patch
However, it no longer works with the current firmware version.
I took the patch from another member and expanded it manually. It would be nice if these modifications were implemented permanently.

After updating to 25.7.3 today, I also had problems with empty aliases.

In my case, manually created aliases were also empty in the diagnostics.

For this reason, none of my rules matched and I had to restore to 25.7.1. Now everything is working again.

--Update--

Habe mein Backup wieder eingespielt (25.7.1) (Proxmox sei Dank) und jetzt geht erstmal wieder alles.

Kleiner Hinweis, wenn ich unter Firewall/Diagnose/Aliase, mittels Schnelleintrag IP Adressen eingetragen habe, haben diese gegriffen.
Es gab aber auch ein zwei Aliase, die funktioniert haben. Keine Ahnung was der Grund dafür war.
Auch ein neues Anlegen eines Alias, konnte das Problem nicht lösen.
Ich konnte auch schön unter Firewall/Aliase/ sehen, dass nur ein zwei Aliase gematcht haben. Alle anderen waren beim Counting bei Null.

 

Hallo,
ich habe ein merkwürdiges Phänomen nach dem Update auf 25.7.3.

Meine selbst angelegten Aliase (Objektgruppen) werden im Regelwerk nicht mehr ausgewertet und alle Regeln, die ein Alias enthalten, werden ignoriert.

Ist das Problem mit der Firmware bekannt? (Ich konnte auf die Schnelle nichts finden) und weiß nicht, ob ich wieder zurückgehe, oder alle Objektgruppen händisch in die Regeln eintragen soll.

VG
Rubinho

Based on the patch provided by vigeland, I have added a few more features.

This makes it possible to use the PPSK mode of Omada WiFi APs.

The following are supported:
Password per user
Default password
Enable default password for all users (who do not have their own password)

I tested the patch with version 25.7.
Is there a way to request these functions for the plugin?

I'm a newbie and have hardly any scripting knowledge, so please be kind to me :)
Attached is the patch...

Okay, I'm on a roll now and have expanded the patch.

I have added the "Default tunnel password for all users" function.

When this box is checked, every user who has not entered their own tunnel password will be assigned the default password.

I took a look at Git and put something together :)
Attached is a modified patch with a fallback tunnel password, tested on v25.7.

Use at your own risk!

OK, I found the problem.

The change in "/usr/local/opnsense/mvc/app/models/OPNsense/Freeradius/User.xml" was not implemented.
I have now entered it manually.

I have also created a fallback tunnel password.
I made the changes as follows...

Code Select Expand

/usr/local/opnsense/mvc/app/models/OPNsense/Freeradius/General.xml:
                <fallbacktunnelpasswd type="TextField">
                    <Required>N</Required>
                </fallbacktunnelpasswd>
                               
/usr/local/opnsense/mvc/app/controllers/OPNsense/Freeradius/forms/general.xml:
    <field>
        <id>general.fallbacktunnelpasswd</id>
        <label>Fallback Tunnelpassword</label>
        <type>text</type>
        <advanced>true</advanced>
    </field>

/usr/local/opnsense/service/templates/OPNsense/Freeradius/users:

{%       if OPNsense.freeradius.general.fallbacktunnelpasswd is defined %}
       Tunnel-password = {{ OPNsense.freeradius.general.fallbacktunnelpasswd }},
{%       endif %}
Unfortunately, I don't understand the patch syntax, so perhaps the creator of the patch could add that here.

Hello, guys.

Today, I started using an Omada AP and wanted to set up ppsk with dynamic VLAN assignment.
That's when I came across this topic.
I installed the patch and can see the selection in the web UI, but the PPSK is not being applied to the configuration.
Is there something else I need to consider, or is the patch incompatible with version 25.7?

kannst du mir erklären, WARUM jeder den Haken bei "Request prefix only" setzt ?

Ich kann der meine Sicht noch erklären.

Habe an diesem Tag das erste Mal einen DG Anschluss in Betrieb genommen und das mit Opnsense und ich habe keinerlei Vorkenntnisse mit Glasfaseranschlüssen.
Bei uns im Saarland ist das noch nicht so weit verbreitet. Und dann kommt da noch Ipv6 mit seinen Eigenheiten.
Um nicht das Rad neu zu erfinden und nicht unnötig in der Weltgeschichte (Bei einer Fehlkonfiguration) rumzufahren, habe ich mich an Settings gehalten, die im Internet dokumentiert wurden und da hinterfrage ich nicht jeden Haken.
Sollte ich mal einen eigenen Glasfaseranschluss bekommen, ist das was anderes. Dann kann ich mit den Settings spielen.
Wenn da mal der Anschluss nicht mehr funktioniert, komme ich immer noch auf den Router/Firewall.

So Problem ist gelöst.

Nachdem ich Zuhause nochmal alles überprüft hatte und nicht wirklich einen Designfehler festellen konnte, habe ich noch etwas recherchiert.
Dabei habe ich gelesen, dass man bei einem Routerwechsel warten muss (bis zu 60 Minuten), erst dann erkennt DGf, dass ein neuer Router vorhanden ist und ich bekomme ne IP.

Gesagt getan, bin ins Auto gesprungen, 50min zu dem Internetanschluss gefahren und hab die Sense wieder in Betrieb genommen. Diesmal ohne die Mac Adresse der Fritzbox zu klonen.

Dabei ist die Sense wie erwartet wieder bei der WAN Konfiguration während des Bootens hängen geblieben. Kurz den Stecker gezogen, weiter ging es.
Danach habe ich den DHCP Prozess wieder neugestartet und habe gewartet. Nach ca. 10min, ich konnte es kaum glauben, kam endlich die IPv4 Adresse.
Und jetzt klappt auch der Reboot der Sense ohne dass das Teil hängen bleibt.

Schönes Restwochenende.

Hallo,

ich wollte gestern eine Opnsense an einem DGf Anschluss in Betrieb nehmen, was leider in die Hose ging.

Hier erstmal die Fakten....

Hardware:
N100 CWWK Appliance
512 Gb NVMe
16Gb DDR5 RAM

Software:
Proxmox 8.4.5 (Host)
Opnsense 25.7 (VM)

WAN Interface enp0s0 (mapped via PCI Passthrough)

Soweit so gut.

Ich hatte die Kiste Zuhause vorbereitet und dafür gesorgt, dass ein Wireguard Tunnel aufgebaut wird, sobald das Internet vorhanden ist.
Das hat Zuhause wunderbar funktioniert. Ich hatte via DHCP eine IPv4 Adresse bekommen und der Tunnel hat sich aufgebaut und ich konnte auf die Kiste remote darauf zugreifen.

Als ich gestern die alte Fritzbox ausbaute, die Sense an das Glasfaser-Modem angeschlossen (Mac Adresse der FB hatte ich übernommen um der Reaktivierung aus dem Weg zu gehen) hatte und die Kiste bootete, bekam ich das erste Problem.
Der Bootvorgang blieb an er Konfiguration des WAN Ports hängen und lief nicht weiter. Ich gehe mal davon aus, dass es mit dem eigentlichen Problem zusammenhängt.
Die Kiste wartete einfach auf eine IPv4 Adresse, die sie nicht bekam und blieb hängen. Ich musste erst den WAN Port ziehen, damit es weiter ging.

Nach dem Bootvorgang schaltete ich noch am WAN Port dhcpv6 ein, setzte das Prefix auf /56, setzte die Haken bei "Nur Präfix anfordern" und "Präfix-Hinweis senden", soweit so gut.

Ich bekam zwar eine lokal IPv6 Adresse, was dem Punkt "Nur Präfix anfordern" geschuldet war, aber trotzdem keine IPv4 und kein Internet.
Danach setzte ich noch im Lan Interface die IPv6 Konfiguration auf Tracking, was dazu führte, dass mein Rechner eine IPv6 Adresse bekam und ich kam dann auch ins Internet. Aber nur via IPv6, da ich nach wie vor keine IPv4 Adresse hatte. Im Übrigen hat sich der Wireguard Tunnel direkt aufgebaut, als IPv6 lief.

Ok dachte ich mir, Reboot tut gut und rebootete die Sense. Leider blieb die Kiste wieder beim Booten am WAN Port hängen und nix ging mehr, bis ich den Port entstöpselte.

Nach ca. 3Std. mit wilden Versuchen die Sense dazu zu bewegen eine IPv4 Adresse zu bekommen, gab ich schließlich auf und habe die Fritzbox wieder eingebaut, die dann direkt eine (CGNAT) Ipv4 Adresse bekam :/

Heute morgen, habe ich die Sense wieder bei mir im LAN angeschlossen und hab direkt eine IPv4 Adresse bekommen.

Ich bin quasi mit meinem Latein am Ende und weiß nicht mehr weiter. Habe ich noch irgendwas vergessen? Muss ich ein Vlan für DGf nutzen, oder gibt es noch einen anderen Trick?

Hi,

läuft denn der Dienst?

Hast du ins Protokoll geschaut?

Darüber hinaus, bedenke noch bei der Umstellung auf Kea, dass die dynamische DNS Registrierung der Clients (noch) nicht funktioniert.
Falls es relevant für dich ist. D.h. du kannst keine Clients mit dem Namen ansprechen, wenn sie sich eine dynamische IP via DHCP gezogen haben.

In naher Zukunft, soll DHCP in DNSmasq aktivierbar sein, inklusive dynamische DNS Registrierung.

https://forum.opnsense.org/index.php?topic=46381.0

VG
Rubinho.

Erstmal danke für die Info.

Ich hab mich gestern für den (vermeintlich) leichten Weg entschieden und die PFsense-Konfig meiner statischen DHCP Einträge und manuellen DNS Einträgen in die Opnsense Konfig mittels Notepad++ konvertiert. Hat mich 15min gekostet und meine Einträge waren drüben.

Da die investierte Zeit überschaubar und die neue Lösung ja noch nicht ogfiziell released ist, kann ich es verkraften, wenn ich in der nächsten Zeit nochmal Hand anlegen muss.

Ich werde mir mal eine DEV Version installieren und mir die neuen DNSmasq Optionen anschauen.

VG
Rubinho

Moin Leute,

ich bin gerade dabei meine letzten beiden Pfsensen auf Opnsense zu migrieren.
Da ich nicht viel von der Pfsense Konfig übernehmen kann/will, werde ich die Opnsense quasi manuell einrichten.

Jetzt stehe ich aber wieder vor der Entscheidung, ISC oder Kea,bzw. Unbound, oder DNSMasq.

Da ich in den Pfsensen isc und unbound nutze, wäre der einfachste Weg, auch wieder auf diese Kombi zu setzen.
Allerdings möchte ich in einem Jahr (Spekulation) nicht alle statischen DHCP Einträge nochmal in KEA eintragen, weil ISC nun entgültig ausgedient hat.

Was mich an Kea momentan noch stört, ist die fehlende dynamische DNS Registration. Statische scheinen ja schon zu funktionieren. Allerdings nicht mit DNSMasq. (So meine Erfahrung)

Das Problem war 2023, als ich mit meiner primären Pfsense gewechselt bin, auch schon, allerdings war Kea da noch relativ frisch am Start und dachte es dauert noch ne Weile bis ISC ausgedient hat. Nun haben wir 2025 und das Thema ist leider immer noch nicht entschieden.

Von daher bin ich mir momentan nicht sicher, was der beste Weg ist.
Grundsätzlich kann ich aber sagen, dass es mir egal ist, welcher Dienst sich durchsetzt und ich am besten einsetzen soll. Es muss DNS Registrion funktionieren + die Standard Funktionen funktionieren.

Gibts da Empfehlungen, oder soll ich weiter auf die Kombi ISC/Unbound setzen?

VG
Rubinho