Recent posts

#1
26.7 Series / Re: OPNsense 26.7.4 - VLAN tra...
Last post by merrins63 - Today at 10:09:21 AM
Hi Patrick

Thanks for replying to my post!

Please see the ifconfig output below. I've redacted a few personal details from the VLAN/interface descriptions, but the underlying configuration and topology remain unchanged, so hopefully it provides everything needed to understand the setup.

My ultimate goal is to move away from Legacy ISC DHCP and transition fully to Kea DHCP. That was actually one of the objectives when I rebuilt the router from scratch on OPNsense 26.7.4.

At the moment, the bridged VLAN configuration is working correctly with Legacy ISC DHCP, whereas I have been unable to achieve the same result with Kea.

Thanks again for taking the time to look at this.
----------------------------------------------------
root@OPNsense:~ # ifconfig

ix0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4803828<VLAN_MTU,JUMBO_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,HWSTATS,MEXTPG>
ether (redacted MAC)
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

ix1: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4803828<VLAN_MTU,JUMBO_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,HWSTATS,MEXTPG>
ether (redacted MAC)
hwaddr (redacted MAC)
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

igc0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: TRUNK (lan)
options=4902028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,NETMAP,HWSTATS,MEXTPG>
ether (redacted MAC)
inet 10.100.14.1 netmask 0xfffffff8 broadcast 10.100.14.7
groups: Interface_GROUP
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

igc1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: WAN (wan)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether (redacted MAC)
inet6 (redacted IPv6)
groups: Interface_GROUP
media: Ethernet autoselect
status: no carrier
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000
inet 10.100.100.1 netmask 0xffffffff
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

enc0: flags=0 metric 0 mtu 1536
options=0
groups: enc
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

pflog0: flags=0 metric 0 mtu 33152
options=0
groups: pflog

pfsync0: flags=0 metric 0 mtu 1500
options=0
maxupd: 128 defer: off version: 1500
syncok: 1
groups: pfsync

lagg0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: LAGG_INTERFACE (opt1)
options=4903828<VLAN_MTU,JUMBO_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,NETMAP,HWSTATS,MEXTPG>
ether (redacted MAC)
hwaddr 00:00:00:00:00:00
inet 10.100.23.1 netmask 0xfffffff8 broadcast 10.100.23.7
laggproto lacp lagghash l2,l3,l4
laggport: ix0 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
laggport: ix1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
groups: lagg
media: Ethernet autoselect
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

vlan0.1.10: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: (redacted VLAN 10 interface)
options=4000000<MEXTPG>
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

vlan0.2.10: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: (redacted VLAN 10 interface)
options=4000000<MEXTPG>
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 10 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

vlan0.1.15: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: (redacted VLAN 15 interface)
options=4000000<MEXTPG>
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
media: Ethernet autoselect
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

vlan0.2.15: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: (redacted VLAN 15 interface)
options=4000000<MEXTPG>
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 15 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

vlan0.1.20:
description: (redacted VLAN 20 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
status: active

vlan0.2.20:
description: (redacted VLAN 20 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 20 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active

vlan0.1.30:
description: (redacted VLAN 30 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 30 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
status: active

vlan0.2.30:
description: (redacted VLAN 30 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 30 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active

vlan0.1.35:
description: (redacted VLAN 35 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 35 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
status: active

vlan0.2.35:
description: (redacted VLAN 35 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 35 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active

vlan0.1.40:
description: (redacted VLAN 40 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 40 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
status: active

vlan0.2.40:
description: (redacted VLAN 40 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 40 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active

vlan0.1.45:
description: (redacted VLAN 45 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 45 vlanproto: 802.1q vlanpcp: 0 parent interface: lagg0
status: active

vlan0.2.45:
description: (redacted VLAN 45 interface)
ether (redacted MAC)
groups: vlan (redacted VLAN groups)
vlan: 45 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (2500Base-T <full-duplex>)
status: active

bridge0:
description: BRIDGE_VLAN10_INTERFACE
ether (redacted MAC)
inet 10.100.10.1 netmask 0xffffff00 broadcast 10.100.10.255
proto rstp maxaddr 2000 timeout 1200
member: vlan0.2.10 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        port 11 priority 128 path cost 20000 vlan protocol 802.1q
member: vlan0.1.10 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        port 10 priority 128 path cost 55 vlan protocol 802.1q
groups: bridge (redacted bridge groups)

bridge1:
description: BRIDGE_VLAN15_INTERFACE
ether (redacted MAC)
inet 10.100.15.1 netmask 0xffffff00 broadcast 10.100.15.255
proto rstp maxaddr 2000 timeout 1200
member: vlan0.2.15 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        port 13 priority 128 path cost 20000 vlan protocol 802.1q
member: vlan0.1.15 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
        port 12 priority 128 path cost 55 vlan protocol 802.1q
groups: bridge (redacted bridge groups)

bridge2:
description: BRIDGE_VLAN20_INTERFACE
ether (redacted MAC)
inet 192.168.50.1 netmask 0xffffff00 broadcast 192.168.50.255
proto rstp maxaddr 2000 timeout 1200
member: vlan0.2.20 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
member: vlan0.1.20 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
groups: bridge (redacted bridge groups)

bridge3:
description: BRIDGE_VLAN30_INTERFACE
ether (redacted MAC)
inet 10.100.30.1 netmask 0xffffff00 broadcast 10.100.30.255
member: vlan0.2.30 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
member: vlan0.1.30 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
groups: bridge (redacted bridge groups)

bridge4:
description: BRIDGE_VLAN35_INTERFACE
ether (redacted MAC)
inet 10.100.35.1 netmask 0xffffff00 broadcast 10.100.35.255
member: vlan0.2.35 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
member: vlan0.1.35 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
groups: bridge (redacted personal bridge groups)

bridge5:
description: BRIDGE_VLAN40_INTERFACE
ether (redacted MAC)
inet 10.100.40.1 netmask 0xffffff00 broadcast 10.100.40.255
member: vlan0.2.40 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
member: vlan0.1.40 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
groups: bridge (redacted personal bridge groups)

bridge6:
description: BRIDGE_VLAN45_INTERFACE
ether (redacted MAC)
inet 10.100.45.1 netmask 0xffffff00 broadcast 10.100.45.255
member: vlan0.2.45 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
member: vlan0.1.45 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
groups: bridge (redacted personal bridge groups)

zen0:
flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1500
groups: tun (redacted VPN group)
---------------------------------------------------------------------
#2
26.7 Series / Re: OPNsense 26.7.4 - VLAN tra...
Last post by Patrick M. Hausen - Today at 08:13:33 AM
Can you post the full output of "ifconfig", please? You can remove public IP addresses.
#3
26.7 Series / Re: OPNsense 26.7.4 - VLAN tra...
Last post by merrins63 - Today at 08:03:39 AM
Hi Team

I have found that there is a bug, meaning I have found the root cause of the issue

The issue is that when you use Bridged VLANs, you cannot use Kea DHCP, it simply doesnt allow you to connect

When you use Bridged VLANS, you must use ISC Legacy DHCP, I have confirmed my connection issue is resolved

If anyone in the OPNsense forum knows how to report a bug, as I believe this is a bug in the system

Regards
#4
French - Français / OPNsense : une alerte firewall...
Last post by gonz - Today at 06:54:52 AM
Bonjour, petit retour parce que ça m'a fait tiquer la semaine dernière et je me suis dit que ça pouvait servir à d'autres. Je surveille régulièrement les états firewall sur mon OPNsense (réseau de ma boîte, électricité/domotique à Valence) et il y a trois semaines, je vois débarquer une série de connexions vers l'IP publique de mon site vitrine.

Une trentaine de requêtes groupées sur deux jours, toutes vers le même hébergeur externe où je gère l'accès admin en VPN depuis mon réseau. Sur le coup j'ai flippé un peu, je me suis dit qu'on tentait un truc genre scan ou bruteforce sur l'admin... J'étais à deux doigts de monter une règle de blocage par précaution sur l'IP source...

Et puis en creusant un peu (logs, horodatage, user agent), j'ai capté que c'était Patrice Decoeur, consultant SEO, que j'avais contacté pour un diagnostic gratuit de mon site, qui passait un outil d'audit dessus. Ça correspondait pile aux dates où j'avais échangé avec lui pour la refonte du site. Du coup fausse alerte, mais ça m'a rappelé de toujours vérifier l'origine avant de bloquer bêtement, on a vite fait de couper un truc légitime sans le savoir. Vous faites comment de votre côté pour distinguer rapidement ce genre de requêtes d'une vraie tentative de scan ou de bruteforce ?
#5
It's both interesting and annoying how well a system can work with slightly defective RAM. I got a used PC from a buddy (who is unlikely to fake it) and it had a RAM error that would only manifest in memtest86+ at around the 5th pass, and only in test #8, who never noticed any problems, even when specifically asked about it. That's why one successful memtest run is just a starting point and a complete build is being left to test for as long as possible but never less than 24 hours total (might interleave some installation or other use), even longer (up to 1 week continuous) if it's going to be used for anything important like a server of any sort. none of this helps if the defect manifests only after a year of use, which is why I'd like OPNSense (or rather: every appliance OS) to have some sort of lightweight user-mode background testing service.
Quote from: moonman on August 18, 2026, 01:25:56 AMcompare CPU load on rtl8127. Copying single 50GB file from the unraid server (with AQC113 NIC) throughput was all over the place from 900 MB(yte)/s to 1.10GB/s with one core maxed out. I put the AQC113 NIC back in and got a stable smooth throughput at 1.09GB/s and none of the cores were maxed out. I did play with different settings including settings RSS queues from 8 to 4, but none helped. Is it a driver issue? maybe
Probably a driver issue, as I was able to get the IRQ load to spread across CPUs on my puny RTL8111 NIC only after much tinkering with the tunables. It's odd that the Windows driver would be just as crappy as the BSD one (even the vendor driver would not do it by itself), especially with much more recent hardware. However, my MoBo had stability issues with MSI-X that had to be resolved through firmware updates, so possibly the driver is just being conservative. May also be a limitation of the OS / networking stack that ties one stream of data to one CPU unless the driver counteracts it. Multiple concurrent streams tend to spread over cores much more readily than a single stream from what little I've looked at.
#6
26.1, 26,4 Series / Re: samplicate pegging cpu
Last post by ubu - Today at 02:40:39 AM
it would've been nice to resolve this but alas I'm going another direction. I'm going to try an Omada Fusion 2.5G Gateway & Controller in One. I got a really good deal on a whole 2.5G kit. Includes the gateway, switch and an AP all for $250 plus I get (5) coupons for the same kit for $50 off so if I can sell them to my customers my kit will be free. It helps me cut down on power usage. Maybe I'll install opnsense in the future on different hardware and give it another shot.
#7
German - Deutsch / Re: [Hardware] Temperaturen
Last post by drosophila - Today at 12:54:57 AM
Quote from: JamesFrisch on September 28, 2026, 07:51:18 AMDer Unterschied ist, dass mit höherer Temperatur [i]alle[/i] (sub)molekularen Prozesse schneller ablaufen, also auch alle Alterungsprozesse in Materialien, Oxidation, Elektromigration usw.Theoretisch, ja. Wie sieht es mit praktischen und echten Effekten aus? Ausfall nach 11 Jahren und einem Monat anstelle von 11 Jahren?
Wohl eher Ausfall kurz nach Ablauf der Garantiezeit vs. Ausfall nach 10 Jahren. Besonders interessant wird es demnächst werden, wenn wir erfahren, ob die Eigenschaften des Niedrigtemperatur-Bleifreilotes zu vorzeitigen Ausfällen führen, weil z.B. durch den niedrigen Schmelzpunnkt thermische Effekte zu Versprödung der Lötungen und somit Kontaktverlust führen. AFAIK steht der massenhafte Einsatz Desselben aber noch aus.
Quote from: JamesFrisch on September 28, 2026, 07:51:18 AMAllerdings habe ich mich auch selten mit der Kühlung von HDDs abgegeben und trotzdem haben es viele ewig überlebt, allerdings kamen die meist nur auf 43°C, keinesfalls und schon gar nicht dauerhaft auf 60°. Also mich würde es stören, ganz besonders bei Hardware, die auf Jahrzehnte hin zuverlässig laufen soll, eine Firewall z.B. .Nun gut, das ist halt deine gefühlte Wahrheit, dass eine HDD auf 43° jahrelang zuverlässig läuft, nicht aber auf 60°.
Rein wissenschaftlich gesehen ist es hingegen irrelevant. Die Hersteller sind ja nicht doof. Die geben aus gutem Grund 5y Garantie und eine Temperaturbereich von 10-60°. Gäbe es auch nur eine 1% Chance eines höhren Ausfalles, wäre der Range 10-55°
Also was denn nun? Anfangs schießt Du dagegen, und nun bist Du dabei (43°->11 Jahre, 60°->5 Jahre)? Außerdem sind die Zeiten, in denen 5 Jahre Garantie bei Festplatten nahezu Standard waren, lange vorbei. Heute bekommt man mit ganz viel Glück noch 3 Jahre als Standard, meistens ist es exakt das gesetzlich vorgeschriebene Minimum von 2 Jahren (nachdem die schon auf 1 Jahr oder sogar weniger runter waren). Alles andere kostet extra als "Garantieverlängerungsoption", was aber rein gar nichts an der geplanten Lebensdauer des Produktes ändert, im Gegensatz zu der von Dir völlig korrekt dargestellten Standardgarantie (mit der Verlängerungsoption be/überzahlt man nämlich genau Deine 1%). Der Hersteller möchte nämlich auch nicht, dass das Gerät deutlich länger hält als die Garantiezeit. "Wissenschaftlich" haben aber keine unserer Einzelerfahrungen irgendeine Relevanz, es wird nicht umsonst für eine aussagekräftige Untersuchung eine Mindestanzahl in den Hunderten und alles unter exakt kontrollierten Bedingungen vorausgesetzt.
Quote from: JamesFrisch on September 28, 2026, 07:51:18 AMwenn man schon nichts weiter unternimmt, sollte man zumindest die natürliche Konvektion / Kamineffekt unterstützenKamineffekt ist bei Computern ein Ammenmärchen. Der wird brutal überschätzt. Das zieht vielleicht bei einem passiven Gehäuse, wenn da aber nur ein einzelner 80mm Lüfter dreht, ist Feierabend. Du könntest eine Case mit einem 120mm Lüfter am Heck auf den Rücken stellen (so dass er voll gegen den Kamineffekt arbeiten müsste) und könntest vermutlich keinen Temperaturunterschied messen.
Mir ist schon klar, daß es beim stinknormalen PC-Gehäuse keinen Kamineffekt gibt, dazu sind die Dimensionen (Höhe vs. Breite) viel zu weit vom Notwendigen weg, selbst ohne den ganzen Krempel im Inneren. Da hat man nur die natürliche Konvektion, die nicht identisch mit dem Kamineffekt ist. Bei Geräten wie einer Firewall-Appliance, einem Switch o.Ä., insgesamt alles, was mit 1HE oder sogar nur 0,5HE daherkommt, sieht das aber anders aus, und darum ging es AFAICS beim OP?
Quote from: JamesFrisch on September 28, 2026, 07:51:18 AMSorry für den Rant, aber ich kann solche "gefühlten Wahrheiten" nicht unkommentiert im Raum stehen lassen. Es ist bewusst provokant geschrieben und ich habe nicht für jede meiner Behauptungen selbst einen wissenschaftlichen Beweis. Den muss ich IMHO aber auch nicht erbringen, da ich die Behauptungen nicht in den Raum gestellt habe. Dies soll lediglich als kritischer Denkanstoss gelesen werden.
Dem kann ich mich nur anschließen: ich wollte und konnte solche Behauptungen wie "60° ist kein Problem, und 80° auch nicht" genausowenig im Raum stehen lassen. Besonders nicht, wenn ich gegenteilige Erfahrungen gemacht habe (3 identische Laptopplatten, eine mit 61° Maximaltemp, eine mit 43° Maximaltemp und eine mit 23° Maximaltemp für je etwa 1000h. Nach ca. 3 Jahren im Dauerbetrieb mit geringer Last aber aktiver Kühlung bei ca. 23° bekam zuerst die 61er defekte Sektoren, 1 Jahr später die 43er und die 23er war noch immer fehlerfrei, als der ganze Stapel weitere 2 Jahre später außer Betrieb genommen wurde). Die Garantiezeit haben sie somit alle überstanden, die war bei denen damals noch 3 Jahre. Zu SSDs kann ich noch keine Aussage machen, weil ich dafür zu wenig Langzeiterfahrungen damit sammeln konnte.

Bei Prozessoren hat man sich an die hohen Temperaturen gewöhnt, weil die internen Sensoren im Die integriert sind und daher ungefähr die Kerntemperatur Tj messen, wohingegen alle externen Sensoren (also in Festplatten und anderen Geräten) schon bestenfalls nur noch die Gehäusetemperatur eines Bauteils messen können, die gern mal 30° niedriger als die Kerntemperatur ist. Bei Festplatten dann sowieso nur noch die Temperatur an einer, hoffentlich sinnvoll gewählten, Stelle. Zudem ist dann das Gerät auf Temperaturen an dieser Stelle ausgelegt, nicht aber darauf, komplett und dauerhaft so heiss zu sein, wie es aber wird, wenn es mit einer Heizung (AKA CPU) in einem lüfterlosen, verschlossenen Gehäuse eingesperrt ist.
Unabhängig von der Kühlsituation ist aber eine Auslegung des Gerätes mit genug Toleranz essenziell für Zuverlässigkeit. Nicht umsonst wird bei Billigprodukten gern die Hälfte der VRM-Komponenten nicht bestückt, weil es ohne diese halt meistens auch die Garantiezeit gerade so übersteht. Aber selbst (besonders?) Billighardware lebt länger, wenn man sie anständig kühlt. Ich habe jedenfalls lieber seltener Downtime bei (semi-)kritischer Infrastruktur als häufigen Tausch, selbst wenn auf Garantie, und gerade bei Datenträgern steht der physische Tausch des Gerätes in keinem Verhältnis zum restlichen Aufwand, das Gesamtsystem wieder betriebsbereit zu machen (z.B. Backups zurückzuspielen dauert deutlich länger als der eigentliche Komponententausch, und wenn das Ersatzteil nicht nahezu identisch ist, kommt noch anderer Vorbereitungsaufwand hinzu).

Mir ist aber eigentlich vollkommen schnuppe, was der OP macht, meinetwegen kann er das Teil auch in eine Heizdecke einpacken oder bei 80° in den Backofen stellen. ;)
#8
German - Deutsch / VPN config Frage
Last post by oelk - September 28, 2026, 10:52:48 PM
Hallo,

welche Rolle spielt die Reihenfolge der Einträge in der Datei /var/etc/openvpn/server.conf?
Ich habe eine Installation vor mir, in der zuerst ein 'register-dns' kommt und die ganzen anderen Einträge.

Müsste man nicht zuerst
dhcp-option DNS 10.100.0.1
..
..
Und zum Schluß ein
register-dns
setzen?

Oder ist das egal?

Gehe ich richtig in der Annahme, das aus diesen Einträgen das Client Zertifikat erzeugt wird?

Und wenn ich jetzt auf dem Server die Reigenfolge ändere bzw überhaupt eine Änderung vornehme, funktioniert das ganze dann nicht mehr?

opnsense: 26.1.11_6 (ja, update ist geplant)

MfG
#9
26.7 Series / Re: [26.7.4_1]Intermittent con...
Last post by dragao-azul - September 28, 2026, 08:24:21 PM
Sorry for the multiple updates: Had problems pretty much immediately.

I've tried `sysctl kern.timecounter.hardware=ACPI-fast` and got the issue within 5 minutes of this change. In fact, multiple times, same frequency as before, so I'll revert...

Differences I can think of apart from the config above is the direct WAN connection instead of the intermediate router - but this was working before.
#10
26.7 Series / Unbound at Reboot does not cre...
Last post by IsaacFL - September 28, 2026, 08:16:54 PM
If I reboot opnsense and I dig opnsense.mydomain.com aaaa, I get no answer.  If I restart unbound manually after boot, then I get expected answer.

This causes me to be unable to access the opnsense web interface from my ipv6 only clients if I reboot the router.