Recent posts

#1
26.1, 26,4 Series / Re: OPNsense 26.1.8_5 Freezes ...
Last post by blen01 - Today at 11:44:20 PM
Has anyone made progress with this issue? I'm still getting hard freezes in 26.1.9. I suspect its either vlans or possibly wireguard. Its pretty much impossible to figure out what is going on due to the logs not saying anything. The system just freezes.
#2
General Discussion / Re: Password Reset
Last post by cookiemonster - Today at 11:37:24 PM
Single user mode as per https://docs.opnsense.org/troubleshooting/password_reset.html but you need to be able to use the console, either physical or in this case virtual. So if you can't get to it, there is no way to change it.
#3
26.1, 26,4 Series / Re: "The DHCP Server is active...
Last post by clarknova - Today at 10:49:42 PM
Ok, I installed the ISC-DHCP plugin, disabled it on WAN, then was able to set my WAN IPv4 to DHCP. Looking at the updated config file, it looks like I just needed to remove the '<enable>1</enable>' line altogether.

Can I make a feature request here? It would be great if OPNsense would remove this line when the ISC-DHCP plugin is not installed, or ignore it when configuring the WAN interface.
#4
26.1, 26,4 Series / Re: "The DHCP Server is active...
Last post by clarknova - Today at 10:44:18 PM
I downloaded the config file and found this:
  <dhcpd>
    <lan>
      <range>
        <from>192.168.97.10</from>
        <to>192.168.97.245</to>
      </range>
    </lan>
    </wan>
      <enable>1</enable>
      <ddnsdomainalgorithm>hmac-md5</ddnsdomainalgorithm>
      <numberoptions>
        <item/>
      </numberoptions>
      <range>
        <from>192.168.2.100</from>
        <to>192.168.2.110</to>
      </range>
      <winsserver/>
      <dnsserver/>
      <ntpserver/>
    </wan>
  </dhcpd>

I changed the 1 to a 0 and uploaded the config, but I'm still seeing the error. I believe this is a remnant from when I was running ISC DHCP server in 24.7.x. I used 'opnsense-bootstrap -r 26.1' to get up to date, but I guess this part of the config was left behind. I'm not sure how to remove it properly.
#5
26.1, 26,4 Series / "The DHCP Server is active on ...
Last post by clarknova - Today at 10:34:32 PM
26.1.9

I had to enable the Dnsmasq DHCP on my WAN interface temporarily to access a modem that was connected there. Once done, I disabled Dnsmasq and removed all options and scopes. Then I tried to change the WAN's IPv4 configuration from static to DHCP and got the red notice:

The following input errors were detected:

    The DHCP Server is active on this interface and it can be used only with a static IP configuration. Please disable the DHCP Server service on this interface first, then change the interface configuration.

I confirmed that Dnsmasq and Kea are disabled. ISC plugin is not installed. The Services widget on the dashboard doesn't list any DHCP server. I even rebooted, but the error persists.

How do I get rid of this error message so I can enable the DHCP client on the WAN interace?
#6
German - Deutsch / Re: Unbound unter OpenVPN
Last post by viragomann - Today at 08:26:19 PM
Quote from: trixter on Today at 11:06:51 AM
QuoteClients am LAN könnten eben so gut ihre DNS-Anfragen an die Management-IP richten. Wenn da ein DNS läuft und die Firewall-Regen den Zugriff erlauben, werden sie eine Antwort erhalten.

Sowas würde ich schon aus Prinzip nicht machen - Lan-Traffic hat am Management-Interface per se nichts zu suchen!
Aufs Manangement-Interface würde der Traffic auch nicht kommen, davon war nicht die Rede.
Aber ein Gerät im LAN spricht einen Service-Port der Management-IP an. Erlauben die Firewall am LAN den Zugriff, so wird er auch erfolgreich sein.
Dazu muss das Paket gar nicht das Management-Interface passieren. Und eben darum kommen die Regeln auf diesem für den Zugriff aus dem LAN auch nicht zum Tragen. Dass du da bspw. den Zugriff auf die Quelle MM Netz eingeschränkt hat, hilft also nicht, wenn der Zugriff über ein anderes Interface reinkommt.

D.h. die den Interfaces zugewiesenen IPs sind allem voran der OPNsense zugewiesen und die darauf betriebenen Services lauschen auf all diesen und scheren sich normalerweise nicht, durch welches Interface ein Zugriff rein kommt. Das gilt auch für Unbound.

Also nochmals:
Wenn eine Regel, die auf einem Interface definiert ist, den Zugriff auf eine IP der OPNsense erlaubt, so ist von dem jeweiligen Interface Zugriff auch möglich.

Deshalb solltest du dir deine Regeln genau ansehen, anstatt dich auf Service-IPs zu verlassen. Da wiegst du dich in falscher Sicherheit.
Hast du eine Pass-Regel mit Ziel "any", so erlaubt sie den Zugriff auf alle Interface-IPs. Ist das Ziel "RFC 1918", ist der Zugriff wahrscheinlich auf die meisten deiner IPs erlaubt.

Grundsätzlich lauschen Services auf allen IPs, die der OPNsense zugewiesen sind, egal welchem Interface, es sei denn, der Service ist explizit für bestimmte IPs konfiguriert. Letzteres ist das, was du mit der Interface-Auswahl in Unbound machst.
Ist hier WAN nicht dabei, wäre dennoch ein Zugriff aus dem WAN auf bspw. die DMZ-IP möglich, wenn es die Regeln erlauben.

Die Management-IP war als Extrem-Beispiel gedacht, weil diese oft als heilige Kuh angesehen wird und man diese streng schützen möchte. Im Grunde ist sie nichts weiter als jede beliebige andere IP, die OPNsense zugewiesen ist. Zur heiligen Kuh machen sie erst die Firewall-Regeln, jedoch alle zusammen, auch jene auf anderen Interfaces.

Ebenso kann die OPNsense GUI nur mit Firewall-Regeln vor unerwünschten Zugriffen geschützt werden. Was du in System: Settings: Administration: Listen Interfaces an Interfaces auswählst, sind lediglich die IPs, auf denen sie erreichbar ist.
Hier hast du wahrscheinlich Management ausgewählt. Hast du auf einem anderen Interface eine Regel die alles auf any oder RFC 1918 erlaubt, und keine entsprechende Block-Regel davor gesetzt, kann man von da aus auch auf die Weboberfläche zugreifen. Das könntest du rasch testen.
#7
German - Deutsch / Re: Protectli VP2430 – 4x 2.5G...
Last post by Jayfrog - Today at 08:23:02 PM
Quote from: ziegler on Today at 07:21:42 PMDanke für Deine Antwort.

Ich habe noch ein Riegel 16GB 1Rr8 PC-5600B-SA0-1010-XT DDR5 SODIMM aus einem HP Mini Elite PC, diesen würde ich dann nutzen wollen.
Der RAM ist quasi neu, wurde nie benutzt.
Die Preise für RAM sind ja heute recht hoch, deshalb nicht extra neu kaufen.
Auch habe ich eien Samsung EVO 960 Plu mit 1 TB noch über.

Das sollte doch mit CoreBoot kompatibel sein, oder?
Hat CoreBoot eigentlich einen Vorteil gegenüber dem "klassischen" bis auf das es opensource ist?
Ich würde nämlich lieber coreBoot nehmen aus dem "Bauch" heraus.

Von den Stats her passt es sogar prima, aber wie ich sagte, können Probleme immer auftreten.

Versuchen würde ich es aber definitiv und wenn es nicht klappt, musst du halt in den sauren Apfel beißen und kaufst
halt einen von Crucial oder Kingston.

Ich kann dir zur Coreboot nicht viel sagen, außer das es keine Probleme macht und wahrscheinlich besseren Support hat, weil für mehr müsste ich das andere
Bios für die Boxen kennen. Dann könnte ich sehen, wie viel mehr Optionen man hat, usw.

Diese Option besteht nämlich durchaus, weil meine Optionen bei Coreboot sehr begrenzt waren.
#8
General Discussion / IPv6 host routes are not remov...
Last post by georgeman - Today at 08:22:37 PM
I recently configured BGP (via os-frr) in order to peer with my ISP so they can properly install an IPv6 route for my /48 prefix. I announce the /48, they announce ::/0, everything works, we are all happy.

But I notice this on Routing -> Diagnostics -> General -> IPv6 routes:



For every single IPv6 that the firewall sees, either internal or public, I get a new /128 entry that is not removed. Right now, after frr has been running for about 12 hours since the last restart, it is showing 6000+ entries. They roughly show up every 20 secs (NDP related?).

Is this normal behavior? Please note these are not currently installed in the kernel, only show up in zebra:

root@opnsense1:~ # netstat -rn6 | grep -c fdXX:XXXX:XXXX:XXXX::XXXX
0
root@opnsense1:~ # vtysh -c "show ipv6 route fdXX:XXXX:XXXX:XXXX::XXXX"
Routing entry for fdXX:XXXX:XXXX:XXXX::XXXX/128
Known via "kernel", distance 0, metric 0
Last update 00:01:03 ago
Flags: None
Status: Installed
* directly connected, vmx0_vlan788
Routing entry for fdXX:XXXX:XXXX:XXXX::XXXX/128
Known via "kernel", distance 0, metric 0
Last update 00:01:58 ago
Flags: None
Status: Installed
* directly connected, vmx0_vlan788
Routing entry for fdXX:XXXX:XXXX:XXXX::XXXX/128
Known via "kernel", distance 0, metric 0
Last update 00:02:34 ago
Flags: None
Status: Installed
* directly connected, vmx0_vlan788

...

(222 similar entries in total)
(Yes, I know it's pointless to obfuscate ULAs)

Is this just cosmetic or something is leaking badly?

Thanks!
#9
26.1, 26,4 Series / Re: Opnsense randomly (?) cras...
Last post by Nullman - Today at 08:22:11 PM
Quote from: meikel on Today at 08:10:22 PMSadly both ram sticks had no issues after 30min.
30 minutes is not enough.
Quote from: meikel on Today at 08:10:22 PMI tried running a live debian13 and the device hung after some seconds on the desktop.
That rules out SSD issue.
Quote from: meikel on Today at 08:10:22 PMI improved cooling (airflow) even though I don't think this is the issue (the issue persists even after the cooling body feels way cooler now).
Improving the airflow wont fix bad thermal contact between heat sink and the cpu. Also, bad thermal contact can cause overheating even if your case is cold to the touch.
Quote from: meikel on Today at 08:10:22 PMI also replaced the CMOS battery as a friend suggested this can be the root cause of such issues but no luck here either.
CMOS is active only when you turn on your system. Once POST is completed, it does nothing.

Quote from: meikel on Today at 08:10:22 PMI will wait for the serial cable and try to debug that way. In the meantime I might try to update the bios of the mainboard.
You should not update anything until you find what the problem is.

Quote from: meikel on Today at 08:10:22 PMI also have to correct myself: the SSD is not running in raid1. It's a single SSD but as a live OS is also crashing I assume it's not the SSD. I also doubt that a faulty SSD crashes the whole machine.

Yeah SSD is not the issue here. You are probably dealing with either faulty memory, faulty motherboard, or faulty power supply.
#10
26.1, 26,4 Series / Re: Opnsense randomly (?) cras...
Last post by meikel - Today at 08:10:22 PM
Quote from: Patrick M. Hausen on Today at 04:36:36 PMDoes your device have a serial console? If yes, connect a PC with a terminal program and let that run until the next crash. The serial console output will not be cleared on reboot unlike VGA/HDMI.

I just ordered a serial cable and will try that. I noticed in the flashy screen that there were a lot of hex codes so I ran me test.

Sadly both ram sticks had no issues after 30min.

I tried running a live debian13 and the device hung after some seconds on the desktop.

I improved cooling (airflow) even though I don't think this is the issue (the issue persists even after the cooling body feels way cooler now).

I also replaced the CMOS battery as a friend suggested this can be the root cause of such issues but no luck here either.

I will wait for the serial cable and try to debug that way. In the meantime I might try to update the bios of the mainboard.

I also have to correct myself: the SSD is not running in raid1. It's a single SSD but as a live OS is also crashing I assume it's not the SSD. I also doubt that a faulty SSD crashes the whole machine.