Messages

Good morning Patrick,

thank you so much for your fast response - you made my day!

After modifying the BIOS settings i was able to install OPNsense as expected.

I´ll also look at the task BIOS update which i haven´t done yet.

Now i know what i´ll have to do on every older hardware if i´m onsite and there is a chance to reboot the OPNsense :-)



Thank you once again and best regards
Norbert

Hey all,

i need help for installation OPNsense on a DEC3850 after SSD failure....

When i try to install OPNsense 25.1 using the serial image the boot hanges:

uart0: <8250 or 16450 or compatible> port 0x3f8-0x3ff irq 3 flags 0x10 on acpi0
hwpstate0: <Cool`n'Quiet 2.0> on cpu0
Timecounter "TSC" frequency 1497186928 Hz quality 1000
Timecounters tick every 1.000 msec
ugen0.1: <AMD XHCI root HUB> at usbus0
Trying to mount root from ufs:/dev/ufs/OPNsense_Install [ro,noatime]...
uhub0 on usbus0
uhub0: <AMD XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
uhub0: 8 ports with 8 removable, self powered
ugen0.2: <USB SanDisk 3.2Gen1> at usbus0
umass0 on uhub0
umass0: <USB SanDisk 3.2Gen1, class 0/0, rev 3.20/1.00, addr 1> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x4001
umass0:1:0: Attached to scbus1
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
Root mount waiting for: CAM
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <WDC WDS480G2G0B-00EPW0 UK870400> ACS-3 ATA SATA 3.x device
ada0: Serial Number 2053GY456803
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 457862MB (937703088 512 byte sectors)
ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN>
da0 at umass-sim0 bus 0 scbus1 target 0 lun 0
da0: <USB SanDisk 3.2Gen1 1.00> Removable Direct Access SPC-4 SCSI device
da0: Serial Number 09011c2226549970219a5a707c95339179ce167c60f41825b2586234f2fd
da0: 400.000MB/s transfers
da0: 29340MB (60088320 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)


i´ve already another SSD - no change. Is the mainboard defect or what do you think?


Best regards
Norbert

Hello all,

i´m migrating currently several OpenVPN Servers to Instances because they are end of life, so far so good.

There is only one option i didn´t find yet: Where can i setup the auth-nocache parameter?


Best regards from Germany
Norbert

Funktioniert!

Danke!

Ich liege Dir zu Füßen, genau der Haken war es! Werde nachher mal noch Hilfe lesen wenn ich mit der Mailübernahme durch bin...


Gruß
Norbert

Hallo Freunde der OPNsense,

ich stehe gerade gedanklich komplett auf dem Schlauch und bräuchte mal kurz einen Schups in die richtige Richtung...

Ich habe Richtung Internet bei mir OPNsense im Einsatz die auch munter VPN Verbindungen macht, soweit alles schick.

Jetzt brauche ich aber intern für Testzwecke temporär eine zweite OPNsense um intern verschiedene eine zweite OPNsense die intern die benötigten Netze hat (die die WAN seitige per VPN kennt) und einfach NAT in eines der Netz der Haupt OPNsense macht. Tut alles, soweit so schön.

Aber: jetzt wäre es natürlich schön, wenn ich aus dem "Transfernetz" zwischen beiden OPNsense die Möglichkeit hätte administrativ auf die temporäre, zweite OPNsense zu kommen. Sollte ja eigentlich ganz einfach sein - dachte ich zumindest...

Da es ein 192.168er Netz zwischen den beiden OPNsense ist müssen logischer Weise die beiden Haken für Block private networks und  Block bogon networks entfernt werden, das ist klar. Dann noch eine Regel auf dem Interface die allen Traffic aus dem WAN Netz erlaubt. Diese Regel greift auch, ich sehe im Live view den Traffic als erlaubt, aber weder http noch https der zweiten OPNsense funktionieren...

Was habe ich vergessen?

Liebe Grüße aus BaWü
Norbert

Hallo Freunde der OPNsense,

wie vermutlich einige von euch habe ich vor V23.1 mit den jetzt als legacy eingestuften Verbindungen gearbeitet welche für mich als früheren Bintec User verständlich waren, auch wenn natürlich die Menge an Optionen ein ganz anderes Kaliber ist.

Um aber endlich mit der aktuellen Technik vertraut zu werden habe ich mir auf meinem Laptop einfach zwei OPNsense als VirtualBox VMs eingerichtet und dahinter jeweils ein Windows System um so die Verbindungen zu testen und die OPNsense zu bedienen.

Leider stehe ich mit manchen Optionen noch auf Kriegsfuß, vielleicht bin ich aber auch einfach nur zu blöd meine Denkweise auf die neue Technik zu ändern...

Mir fehlt gleich im ersten Schritt schon etwas ganz entscheidendes: Wie definiere ich denn, wer der Verbindung aufbaut und wer nur Responder ist? Das einzige was ich bislang gefunden habe sind unter Children die Start und Stop Actions - bin ich da richtig?

Wenn ja, ist das dann richtig wenn eine Seite keine actions definiert hat und die zweite beides auf Start hat damit diese die Verbindung aufbaut und auch bei Abbau erneuert?


Vielen Dank schon mal für Schupser in die richtige Richtung
Norbert

Sehe ich das richtig, wird das nur funktionieren wenn wir nicht die klassischen IPsec Verbindungen nehmen sondern auf die neuen Connections wechseln die mit V23.1 eingeführt wurden? Bei den klassischen Verbindungen lässt sich nämliche jede Remote IP nur einmal einrichten...


Gruß
Norbert

Und wenn ich mehrere dieser Nebenstellen habe? Kann eine Adresse ja nur einmal über alle Tunnel hinweg vergeben (wie ich gerade lernen durfte)


Norbert

Hallo Freunde der OPNsense,

vermutlich bin ich nur zu doof meine Frage richtig zu formulieren, aber vielleicht könnt ihr mir ja weiterhelfen.

Ich habe ein Problem mit IPsec auf der OPNsense was LTE Router (und wegen Standort geht nichts anders) angeht: Diese haben ja keine öffentliche IP, sprich ich kann sie weder per DynDNS noch Public IP im Setup konfigurieren, nur wie schaffe ich es dann eine eingehende VPN Verbindung einzurichten?

Im Firewall LOG sehe ich von drei IPs eingehende UDP 500 Verbindungen, nur meine Idee einer Einrichtung der Verbindungen mit Dummy DNS Namen und Aktivierung der Option Allow any remote gateway to connect hat bei mir nicht funktioniert.

Wie bekomme ich sowas trotzdem ans laufen? Bei der vorher genutzten Bintec war einfach die Hostadresse der Gegenstelle leer und die Verbindungen wurden efolgreich aufgebaut, nur das erlaubt ja die OPNsense nicht...

Gruß
Norbert

Hey Ronny,

und was hilft mir das beim Versuch das per Skript zu machen? Muss ich jetzt jeden Host doppelt pflegen? Also sowohl in den Skripten als auch der OPNsense? Wieso jetzt doppelte Arbeit? Bei rund 100 Clients pro Standort in den pädagogischen Netzen ist das bissel viel Arbeit - daher die Frage ob das doppelte Geschäft wirklich notwendig ist


Gruß
Norbert

Hast schon recht, nur reden wir bei meinem Problem ja nicht von einem Client der per DHCP die DNS Informationen und damit auch Server bekommen kann sondern von Site to Site, daher war die Problematik nur über die Anpassung im Routing zu lösen

Norbert

Hallo Freunde der OPNsense,

ich hoffe mal ich bin nicht der einzige unter uns der gerne Wake on LAN benutzt um Clients auch mal aus der Ferne anschalten zu können ohne dafür extra vor Ort zu sein - so mache ich das zum Beispiel immer sehr gerne in den Ferien um die Clients mit den aktuellen Updates bespielen zu können, nur leider funktioniert es nicht mehr so wie früher seit wir von Bintec auf die OPNsense umgestiegen sind.

Ich habe mir extra dazu mal ein paar Batchdateien gebaut die die jeweiligen Clients enthalten, die Funktionsweise ist eigentlich sehr einfach:

wake "Mac Adresse" "Broadcast Adresse", exemplarisch wake 84-A9-3E-72-4F-45 192.168.178.255

Wie gesagt - es lief bis zum Wechsel der Router weswegen ich die Clients, das Tool und auch die Adressen komplett ausschließen kann, ebenso funktionieren die Skripte weiterhin wenn ich sie auf einem Host direkt im jeweiligen LAN ausführe, nur sowas muss doch auch remote gehen - nur wie?

P.S.: Müsste ich eigentlich nicht im Firewall LOG der OPNsense das WOL Paket sehen können?


Grüße aus BaWü
Norbert

Hallo Freunde der OPNsense,

ich glaube ich komme meinem Problem mit dem Unbound DNS und der DNS Weiterleitung endlich auf die Spur. So wie früher mit den Gateways anderer Hersteller versuche ich mit der OPNsense eine gefühlte einfache Lösung: DNS Weiterleitung an einen entfernten, nur per VPN erreichbaren DNS Server damit das Active Directory vom Hauptstandort auch per IPsec Tunnel erreichbar ist ohne die Clients direkt auf DNS Server der entfernten Gegenstelle zu schicken.

Heute glaube ich endlich den Grund für meine nicht funktionierende DNS Weiterleitung mit Unbound gefunden zu haben: Er kann den entfernten DNS schlicht und einfach nicht erreichen! Wie ich darauf komme: Versuche ich von einem beliebigen System hinter der Remote OPNsense den zentralen DNS zu pingen klappt das, nicht aber wenn es die OPNsense selber probiert (habe es über die SSH Shell getestet).

Von Bintec Routern kenne ich die IPsec Konfiguration so, das ich im Tunnel konfigurieren muss mit welcher IP der Router selber in den Tunnel kommunizieren darf, sonst würde er nämlich nicht die richtige IP nehmen. Kann es ein das genau hier mein Fehler liegt und ich der OPNsense bei einem IPsec Tunnel sagen muss mit welcher seiner IPs er überhaupt in den Tunnel gehen soll?

Hintergrund: An unserer Schule läuft eine OPNsense 24.1 mit zwei DSL Anschlüssen und mehreren internen Netzen (Verwaltung, Schüler, PBX usw) und daher glaube ich muss der OPNsense sagen mit welcher IP sie in den Tunnel kommunizieren soll.

Ich hoffe mal es ist verständlich wo ich den Knoten sehe und hoffe auf eine schlaue Idee von euch!

Grüße aus BaWü
Norbert

Hach kann die Welt doch einfach sein wenn man nur weiß wie...

Hatte gerade ein kurzes Gespräch mit Ad, und jetzt ist mir seine Erklärung auch endlich verständlich...

Wie verhält sich eine OPNsense intern? Wer mit SSH sich auf ihr anmeldet und die Routing Tabelle ansieht wird feststellen, das nicht eine der VPN Verbindungen die per policy based routing in ihrer Routing  Tabelle sichtbar sind, und damit nutzt sie ihre Standroute beim Versuch eines Ping / DNS Auflösung via VPN oder was auch immer.

Auch wenn sich der Lösungsweg komplett schräg anhört: Er funktioniert! Ad hat es mir einmal gezeigt, ich habe es schon mehrfach nachgebaut...

1.) Unter System: Gateways: Configuration die OPNsense selber mit der LAN IP, die für den VPN Tunnel genutzt werden soll, als Gateway eintragen
2.) Unter System: Routes: Configuration eine Route für das bislang nur per policy baesd routing bekannte Netz anlegen und als Gateway das zuvor unter Punkt 1 angelegte nutzen.

Fertig!

Wer es kontrollieren möchte: mit einem netstat -nr4 vor der Anpassung sieht man nur die LAN Routen (durch die vorhandenen Interfaces) plus PPPoE Verbindungen als default route, mehr nicht. Nach der Anpassung wird die händisch hinzugefügte Route angezeigt und genutzt!

Ich hoffe mal die Erklärung hilft euch, bei Rückfragen einfach melden!

Gruß
Norbert