Messages

[before]

Since I expect more people to run into this lets make it a bit more forgiving:

https://github.com/opnsense/plugins/commit/150ff2ab0fb256d0d242e4fc96a60af7f04e9398

Just for the notes: it still does not work, until i remove the group interfaces from the passive interfaces before the update.
I am updating from 26.1 to 26.7. At least i can prepare the settings now on every appliance und then run the update via cli.
Thanks.

Seems like PHP 8.5.12 is available for 26.7.

I tried today another appliance. Still failes. Migration output:

Code Select Expand

[OPNsense\Quagga\OSPF:interfaces.interface.12acf5f9-e33e-4482-8092-fa1035437f35.interfacename] Option [] not in list.{openvpn}
[OPNsense\Quagga\OSPF:interfaces.interface.e840ea08-c93f-4993-858b-0415c64a79a1.interfacename] Option [] not in list.{wireguard}
Model OPNsense\Quagga\OSPF can't be saved, skip ( OPNsense\Base\ValidationException: [OPNsense\Quagga\OSPF:interfaces.interface.12acf5f9-e33e-4482-8092-fa1035437f35.interfacename] Option [] not in list.{openvpn}
[OPNsense\Quagga\OSPF:interfaces.interface.e840ea08-c93f-4993-858b-0415c64a79a1.interfacename] Option [] not in list.{wireguard}
 in /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php:821
Stack trace:
#0 /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php(946): OPNsense\Base\BaseModel->serializeToConfig()
#1 /usr/local/opnsense/mvc/script/run_migrations.php(69): OPNsense\Base\BaseModel->runMigrations()
#2 {main} )
Failed OPNsense\Quagga\OSPF from 1.1.0 to 1.1.5

Hi,

I am having issues after the latest update.

I have several dozen OSPF clients. Before the update, they were configured only using the "Interfaces" tab, where the Area was also entered. Under "General", I also set some interfaces to "Passive".

After the update, OSPF no longer works:

- The passive interfaces are not transferred (this is not critical).

- In the "Interfaces" menu, the old Area still shows up in the Areas column. However, when I click "Edit", the Area disappears and shows only an empty drop-down menu.

If I manually create the Area with the type "normal" and assign it to the interfaces, everything works normally again.
I tried to create the Area before the update, but stub and nssa do not work in my environment and "normal" isn't available.

Is it possible to fix this issue in the update process?

Bandbreite ist genügend vorhanden, der Cache ist auch komplett deaktiviert.
Squid ist im Einsatz für zentrale Zugriffsverwaltung auf Websiten und das entsprechende Logging.

Hi,

wir haben bei uns einen internen, nur übers VPN erreichbaren DNS-Server, der für die Namensauflösung unserer internen Domain zuständig ist.
Aktuell läuft die Opnsense so, dass die Systemeinstellungen öffentliche DNS-Server vorgeben und der eingebaute dnsmasq per Domainüberschreibung den internen VPN-DNS für die Domain anfrägt.
Vom dnsmasq ist der DNS-Cache per "no-cache" deaktiviert, sodass sofort nach Aufbau des VPN-Tunnels der VPN-DNS die richtigen internen IP's liefert.
Funktioniert auch so, nachgeprüft per nslookup.

Eine der internen Dienste ist eine Website. Die öffentlich aufgelöste IPv4 unterscheidet sich von der intern aufgelösten IPv4.
Ist auch kein Problem für dnsmasq.

Jetzt kommt aber der Squid ins Spiel. Dieser behält, sollte der VPN-Tunnel nicht bestehen, die öffentlich aufgelöste IPv4 im Cache, sodass die falsche Website ausgegeben wird.
Startet man den Squid nach VPN-Aufbau neu, funktioniert alles wieder wie gewollt und die vom VPN-DNS gelieferte IP wird verwendet.
Es ist natürlich auf Dauer keine Lösung, jedes mal alle Squids bei VPN-Neustart o.ä. neuzustarten, da wir eine mittlere zweistellige Standortanzahl haben.

Habt ihr eine Lösung / Option, um den IP-Cache von Squid zu deaktivieren?
Oder andere Lösungsansätze?

Danke für euren Input!

Viele Grüße!